SCHED_ULE / NetGraph interaction broken somwhere between r227874 and r229818

[Andriy Gapon]

on 12/01/2012 12:05 Lev Serebryakov said the following:
> Hello, Andriy.
> You wrote 12 января 2012 г., 13:54:41:
> 
>>>  Switching to 4BSD helps. 4BSD works as usual: all CPU time is
>>>  interrupts and network thread, system is responsive under heaviest load,
>>>  normal operations of DNS, DHCP and hostapd.
>> How reproducible is this result?
>   100%
> 
>> In other words, have you definitely ruled out all other factors besides the
>> scheduler?
> 
>    I have two almost-identical NanoBSD images which differs in one line in kernel
>  config  -- option about scheduler. Worlds are exactly the same, only kernels were
>  rebuilt.
> 
>       Alexander Motin suggests, that switching scheduler could slightly
>  change stack consumption, which triggers switching to ng_queue
>  instead of direct calls.
> 
>     Really, here is diff between "md5" of all files of one and other
>  images:

Well, I mostly meant things like uptime, load level and pattern, etc.
But what mav says makes sense.
Also I remember seeing some very old reports about some strange issues with
SCHED_ULE and dummynet.
Some links that I found:
http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046332.html
http://dadv.livejournal.com/139366.html#cutid1

Given the last link, I wonder if binding the ng_queue thread to a particular CPU
would change anything.

> blob# diff  ~lev/bsd-image.md5sums ~lev/ule-image.md5sums
> 74c74
> < MD5 (./boot/kernel/kernel) = 3bb0dd757628b5065d27ee5e7fc22eb3
> ---
>> MD5 (./boot/kernel/kernel) = 5ba379d2c73e1277566f4bbcb618a9f2
> 618c618
> < MD5 (./conf/base/var/log/userlog) = a827af82c1f780687706b19c7d94b29e
> ---
>> MD5 (./conf/base/var/log/userlog) = fc289b66ae6cb23f9b24b694bf12157b
> 15678c15678
> < MD5 (./var/log/userlog) = a827af82c1f780687706b19c7d94b29e
> ---
>> MD5 (./var/log/userlog) = fc289b66ae6cb23f9b24b694bf12157b
> 


-- 
Andriy Gapon