Date: Sun, 11 Nov 2012 20:24:31 -0800 From: Alfred Perlstein <bright@mu.org> To: Dieter BSD <dieterbsd@engineer.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Memory reserves or lack thereof Message-ID: <2CB113BD-D223-4BCF-AAB8-F3D3FA962168@mu.org> In-Reply-To: <20121112003215.238950@gmx.com> References: <20121112003215.238950@gmx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think very few of the m_nowaits actually need the reserve behavior. We sho= uld probably switch away from it digging that deep by default and introduce a= flag and/or a per thread flag to set the behavior.=20 Sent from my iPhone On Nov 11, 2012, at 4:32 PM, "Dieter BSD" <dieterbsd@engineer.com> wrote: > Alan writes: >> In conclusion, I think it's time that we change M_NOWAIT so that it doesn= 't >> dig any deeper into the cache/free page queues than M_WAITOK does and >> reintroduce a M_USE_RESERVE-like flag that says dig deep into the >> cache/free page queues. The trouble is that we then need to identify all= >> of those places that are implicitly depending on the current behavior of >> M_NOWAIT also digging deep into the cache/free page queues so that we can= >> add an explicit M_USE_RESERVE. >=20 > find /usr/src/sys | xargs grep M_NOWAIT | wc -l > 2101 >=20 > Sounds like a lot of work that would need to happen atomically. > Would this work: >=20 > M_NO_WAIT do not sleep, do not dig deep unless M_USE_RESERVE also se= t > M_USE_RESERVE dig deep > M_NOWAIT M_NO_WAIT | M_USE_RESERVE (deprecated) >=20 > New code avoids using M_NOWAIT. Existing code continues working the same w= ay. > As time permits, old code is converted to new flags. Eventually M_NOWAIT > goes away. >=20 > Pro: the amount of code that needs to change atomically is much smaller. >=20 > Con: (1) Have to remember (or look up) difference between M_NOWAIT > and M_NO_WAIT. Maybe calling the new flag M_NO_SLEEP would help? > (2) Would M_NOWAIT really ever go away? The spl() calls haven't, > even after some cage rattling. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2CB113BD-D223-4BCF-AAB8-F3D3FA962168>