tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: increase softint_bytes



softint_establish() already fails if there is no space, and prints a WARNING in this case. The caller however needs to check for the failure, which ixgbe(4) mostly doesn't. Not sure if that is really the root cause, the panic seems to be actually in different area, and I didn't actually see the warning in the dmesg.

Making softint size fully dynamic is unfortunately not straighforward, it would need to reallocate the softint memory on all CPUs in a way that any serviced softints would continue working during this time. It would be simple however to adjust it based on % of physical memory, instead of fixed value.

If I count correctly, with current 8192 bytes the system supports some 100 softints, which seems to be on quite low side - more advanced hardware and drivers usually use queue and softint per cpu, so it can quickly run out on system with e.g. 32 cores.

I agree that the sysctl seems somewhat unnecessary, since the limit is only relevant during boot anyway, so it's not very helpful.
 
Jaromir

2017-11-16 21:05 GMT+01:00 matthew green <mrg%eterna.com.au@localhost>:
Masanobu SAITOH writes:
>   Hi, all.
>
>   Some device drivers now allocate a lot of softints.
> See:
>
>       http://mail-index.netbsd.org/current-users/2017/11/09/msg032581.html
>
> To avoid this panic, I wrote the following patch:
>
>       http://www.netbsd.org/~msaitoh/softint-20171116-0.dif
>
> Summary:
>
>       - Increase the default size from 8192 bytes to 32768 bytes.
>       - Add new option SOFTINT_BYTES to change the value.
>       - Add two new read-only sysctls kern.softint.{max,count}
>
> Any comment?

can't this be fixed by making it dynamic?  ie, fix it properly so
that it never has this problem again -- if in 10 years we're adding
5x as many softints as today, we'll hit it again.

i also don't see why the crash can't be fixed to become an error.
the code tries to avoid adding more than it can, but soemthing must
be wrong for the crash to occur anyway.  ie, at worst we'd fix it
to return an error instead of crashing.

if that is done, the sysctl exports seem unneccesary as well.

thanks.


.mrg.



Home | Main Index | Thread Index | Old Index