Re: Give users a hint when their locate database is too small.
On Tue, 13 Nov 2012, Eitan Adler wrote: Ack to all. Final patch sent for approval: diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c index b0faefb..95b3fed 100644 --- a/usr.bin/locate/locate/locate.c +++ b/usr.bin/locate/locate/locate.c @@ -292,7 +292,7 @@ search_mmap(db, s) err(1, "`%s'", db); len = sb.st_size; if (len < (2*NBG)) - errx(1, "database too small: %s", db); + errx(1, "database too small: %s\nRun /usr/libexec/locate.updatedb", db); That looks longer than 80 characters, a limit given implicitly in style.9. -Ben if ((p = mmap((caddr_t)0, (size_t)len, PROT_READ, MAP_SHARED, -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Memory reserves or lack thereof
Hey, great catch!
adrian
On 13 November 2012 12:04, Alan Cox wrote:
> On 11/12/2012 11:35, Alan Cox wrote:
>> On 11/12/2012 07:36, Konstantin Belousov wrote:
>>> On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote:
On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov
wrote:
> On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
>> I have a memory subsystem design question that I'm hoping someone can
> answer.
>> I've been looking at a machine that is completely out of memory, as in
>>
>> v_free_count = 0,
>> v_cache_count = 0,
>>
>> I wondered how a machine could completely run out of memory like this,
> especially after finding a lack of interrupt storms or other pathologies
> that would tend to overcommit memory. So I started investigating.
>> Most allocators come down to vm_page_alloc(), which has this guard:
>>
>> if ((curproc == pageproc) && (page_req != VM_ALLOC_INTERRUPT)) {
>> page_req = VM_ALLOC_SYSTEM;
>> };
>>
>> if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved ||
>> (page_req == VM_ALLOC_SYSTEM &&
>> cnt.v_free_count + cnt.v_cache_count >
> cnt.v_interrupt_free_min) ||
>> (page_req == VM_ALLOC_INTERRUPT &&
>> cnt.v_free_count + cnt.v_cache_count > 0)) {
>>
>> The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate
> every last page.
>> >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rare,
> perhaps only used from interrupt threads. Not so, see kmem_malloc() or
> uma_small_alloc() which both contain this mapping:
>> if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT)
>> pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED;
>> else
>> pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED;
>>
>> Note that M_USE_RESERVE has been deprecated and is used in just a
> handful of places. Also note that lots of code paths come through these
> routines.
>> What this means is essentially _any_ allocation using M_NOWAIT will
> bypass whatever reserves have been held back and will take every last page
> available.
>> There is no documentation stating M_NOWAIT has this side effect of
> essentially being privileged, so any innocuous piece of code that can't
> block will use it. And of course M_NOWAIT is literally used all over.
>> It looks to me like the design goal of the BSD allocators is on
> recovery; it will give all pages away knowing it can recover.
>> Am I missing anything? I would have expected some small number of pages
> to be held in reserve just in case. And I didn't expect M_NOWAIT to be a
> sort of back door for grabbing memory.
> Your analysis is right, there is nothing to add or correct.
> This is the reason to strongly prefer M_WAITOK.
>
Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was
well understand that it should only be used by interrupt handlers.
The trouble is that M_NOWAIT conflates two orthogonal things. The obvious
being that the allocation shouldn't sleep. The other being how far we're
willing to deplete the cache/free page queues.
When fine-grained locking got sprinkled throughout the kernel, we all to
often found ourselves wanting to do allocations without the possibility of
blocking. So, M_NOWAIT became commonplace, where it wasn't before.
This had the unintended consequence of introducing a lot of memory
allocations in the top-half of the kernel, i.e., non-interrupt handling
code, that were digging deep into the cache/free page queues.
Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE"
allocation is less likely to succeed than an "M_NOWAIT" allocation.
However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it
could only allocate a free page. M_USE_RESERVE said that it ok to allocate
a cached page even though M_NOWAIT was specified. Consequently, the system
wouldn't dig as far into the free page queue if M_USE_RESERVE was
specified, because it was allowed to reclaim a cached page.
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.
Alan
P.S. I suspect that we should also increase the size of the "page reserve"
that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_all
Re: Memory reserves or lack thereof
On 11/12/2012 11:35, Alan Cox wrote:
> On 11/12/2012 07:36, Konstantin Belousov wrote:
>> On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote:
>>> On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov
>>> wrote:
>>>
On Fri, Nov 09, 2012 at 07:10:04PM +, Sears, Steven wrote:
> I have a memory subsystem design question that I'm hoping someone can
answer.
> I've been looking at a machine that is completely out of memory, as in
>
> v_free_count = 0,
> v_cache_count = 0,
>
> I wondered how a machine could completely run out of memory like this,
especially after finding a lack of interrupt storms or other pathologies
that would tend to overcommit memory. So I started investigating.
> Most allocators come down to vm_page_alloc(), which has this guard:
>
> if ((curproc == pageproc) && (page_req != VM_ALLOC_INTERRUPT)) {
> page_req = VM_ALLOC_SYSTEM;
> };
>
> if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved ||
> (page_req == VM_ALLOC_SYSTEM &&
> cnt.v_free_count + cnt.v_cache_count >
cnt.v_interrupt_free_min) ||
> (page_req == VM_ALLOC_INTERRUPT &&
> cnt.v_free_count + cnt.v_cache_count > 0)) {
>
> The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate
every last page.
> >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rare,
perhaps only used from interrupt threads. Not so, see kmem_malloc() or
uma_small_alloc() which both contain this mapping:
> if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT)
> pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED;
> else
> pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED;
>
> Note that M_USE_RESERVE has been deprecated and is used in just a
handful of places. Also note that lots of code paths come through these
routines.
> What this means is essentially _any_ allocation using M_NOWAIT will
bypass whatever reserves have been held back and will take every last page
available.
> There is no documentation stating M_NOWAIT has this side effect of
essentially being privileged, so any innocuous piece of code that can't
block will use it. And of course M_NOWAIT is literally used all over.
> It looks to me like the design goal of the BSD allocators is on
recovery; it will give all pages away knowing it can recover.
> Am I missing anything? I would have expected some small number of pages
to be held in reserve just in case. And I didn't expect M_NOWAIT to be a
sort of back door for grabbing memory.
Your analysis is right, there is nothing to add or correct.
This is the reason to strongly prefer M_WAITOK.
>>> Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was
>>> well understand that it should only be used by interrupt handlers.
>>>
>>> The trouble is that M_NOWAIT conflates two orthogonal things. The obvious
>>> being that the allocation shouldn't sleep. The other being how far we're
>>> willing to deplete the cache/free page queues.
>>>
>>> When fine-grained locking got sprinkled throughout the kernel, we all to
>>> often found ourselves wanting to do allocations without the possibility of
>>> blocking. So, M_NOWAIT became commonplace, where it wasn't before.
>>>
>>> This had the unintended consequence of introducing a lot of memory
>>> allocations in the top-half of the kernel, i.e., non-interrupt handling
>>> code, that were digging deep into the cache/free page queues.
>>>
>>> Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE"
>>> allocation is less likely to succeed than an "M_NOWAIT" allocation.
>>> However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it
>>> could only allocate a free page. M_USE_RESERVE said that it ok to allocate
>>> a cached page even though M_NOWAIT was specified. Consequently, the system
>>> wouldn't dig as far into the free page queue if M_USE_RESERVE was
>>> specified, because it was allowed to reclaim a cached page.
>>>
>>> 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.
>>>
>>> Alan
>>>
>>> P.S. I suspect that we should also increase the size of the "page reserve"
>>> that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_alloc*(). How
>>> many legitimate users of a new M_USE_RESERVE-like flag in today's kernel
>>> could actually be satisfied by two pages?
>> I am almost sure that most o
Re: Give users a hint when their locate database is too small.
Eitan Adler writes: > What do people think of this? Maybe /usr/libexec/locate.updatedb is a > better pointer? Yes, I would think locate.updatedb(8) would be the appropriate reference, because it's possible to build locate databases in ways and for reasons other than the weekly script. I assume that the precise cutoff value is chosen not because the number of bigrams is important but because the size of the bigram buffer is, and that it's only notated as (2*NBG) because BGBUFSIZE isn't defined in a header... > commit fb03b777daf2c69bb9612902e38fdb25b256be72 > Author: Eitan Adler > Date: Mon Nov 12 22:05:55 2012 -0500 > > Give users a hint when their locate database is too small. > > Reviwed by: ??? > Approved by: ??? > MFC after:3 weeks > > diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c > index b0faefb..f0c8c37 100644 > --- a/usr.bin/locate/locate/locate.c > +++ b/usr.bin/locate/locate/locate.c > @@ -292,7 +292,7 @@ search_mmap(db, s) > err(1, "`%s'", db); > len = sb.st_size; > if (len < (2*NBG)) > - errx(1, "database too small: %s", db); > + errx(1, "database too small: %s\nTry running > /etc/periodic/weekly/310.locate", db); > > if ((p = mmap((caddr_t)0, (size_t)len, > PROT_READ, MAP_SHARED, ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Give users a hint when their locate database is too small.
On Nov 13, 2012, at 8:05 AM, Eitan Adler wrote: > On 13 November 2012 10:58, Eitan Adler wrote: > > Okay... sorry for the spam. I remember there was a reason I used > /etc/periodic/weekly/310.locate instead of /usr/libexec/locate.updatedb. > The latter must not be run as root, and the former takes care of this work. > > Since the default is to enable weekly updates I am inclined to use the > 310.locate script instead. Ok. The only thing about hardcoding an RC script name into a binary is that I felt it was more likely to change whereas locate.updatedb is more constant.. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Give users a hint when their locate database is too small.
On 13 November 2012 11:10, Ian Lepore wrote: > Would it work to refer them to the locate.updatedb manpage (which > references the periodic script, and presumably would be kept up to date > with any script renaming/numbering)? If I could avoid the indirection I'd like to avoid it. "Do this" is more helpful than "See this which tells you what to do." -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Give users a hint when their locate database is too small.
On Tue, 2012-11-13 at 11:05 -0500, Eitan Adler wrote: > On 13 November 2012 10:58, Eitan Adler wrote: > > Okay... sorry for the spam. I remember there was a reason I used > /etc/periodic/weekly/310.locate instead of /usr/libexec/locate.updatedb. > The latter must not be run as root, and the former takes care of this work. > > Since the default is to enable weekly updates I am inclined to use the > 310.locate script instead. > > > Would it work to refer them to the locate.updatedb manpage (which references the periodic script, and presumably would be kept up to date with any script renaming/numbering)? -- Ian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Give users a hint when their locate database is too small.
On 13 November 2012 10:58, Eitan Adler wrote: Okay... sorry for the spam. I remember there was a reason I used /etc/periodic/weekly/310.locate instead of /usr/libexec/locate.updatedb. The latter must not be run as root, and the former takes care of this work. Since the default is to enable weekly updates I am inclined to use the 310.locate script instead. -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Give users a hint when their locate database is too small.
On 13 November 2012 10:55, Eitan Adler wrote: > On 13 November 2012 09:33, Warren Block wrote: > ... > > Ack to all. Final patch sent for approval: > > commit 33ed38e54bf7c7c5f0531afa5501f501e1a67279 > Author: Eitan Adler > Date: Mon Nov 12 22:05:55 2012 -0500 > > Give users a hint when their locate database is too small. > > Reviwed by: wblock > Reviewed by:gcooper > Reviwed by: "Lowell Gilbert" with these typos fixed ;) -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Give users a hint when their locate database is too small.
On 13 November 2012 09:33, Warren Block wrote: ... Ack to all. Final patch sent for approval: commit 33ed38e54bf7c7c5f0531afa5501f501e1a67279 Author: Eitan Adler Date: Mon Nov 12 22:05:55 2012 -0500 Give users a hint when their locate database is too small. Reviwed by: wblock Reviewed by:gcooper Reviwed by: "Lowell Gilbert" Approved by:cperciva MFC after: 3 weeks diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c index b0faefb..95b3fed 100644 --- a/usr.bin/locate/locate/locate.c +++ b/usr.bin/locate/locate/locate.c @@ -292,7 +292,7 @@ search_mmap(db, s) err(1, "`%s'", db); len = sb.st_size; if (len < (2*NBG)) - errx(1, "database too small: %s", db); + errx(1, "database too small: %s\nRun /usr/libexec/locate.updatedb", db); if ((p = mmap((caddr_t)0, (size_t)len, PROT_READ, MAP_SHARED, -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Give users a hint when their locate database is too small.
On Mon, 12 Nov 2012, Eitan Adler wrote: What do people think of this? Maybe /usr/libexec/locate.updatedb is a better pointer? commit fb03b777daf2c69bb9612902e38fdb25b256be72 Author: Eitan Adler Date: Mon Nov 12 22:05:55 2012 -0500 Give users a hint when their locate database is too small. Reviwed by: ??? Approved by: ??? MFC after: 3 weeks diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c index b0faefb..f0c8c37 100644 --- a/usr.bin/locate/locate/locate.c +++ b/usr.bin/locate/locate/locate.c @@ -292,7 +292,7 @@ search_mmap(db, s) err(1, "`%s'", db); len = sb.st_size; if (len < (2*NBG)) - errx(1, "database too small: %s", db); + errx(1, "database too small: %s\nTry running /etc/periodic/weekly/310.locate", db); if ((p = mmap((caddr_t)0, (size_t)len, PROT_READ, MAP_SHARED, Don't use the unsure "try", just say "Run /etc/periodic/weekly/310.locate". And hope it doesn't get renumbered. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: my work on cross-build for mips, arm, etc - your help, please!
you might find some more success with this:
make _TARGET_CROSS_DEFS= LOCALBASE=/usr/obj/mips.mips/rootfs
CONFIGURE_HOST=mips-freebsd LIBTOOL=/usr/local/bin/libtool all
sorry about all the mess! i'm sure most of you out there will be able to
decifer it!
-Original Message-
From: Michael Vale
Sent: Tuesday, November 13, 2012 11:31 PM
To: freebsd-embed...@freebsd.org ; freebsd-po...@freebsd.org ;
freebsd-hackers@freebsd.org
Subject: Re: my work on cross-build for mips, arm, etc - your help, please!
P.S. some of the ${DESTDIR} things i added can be removed!!!
From: Michael Vale
Sent: Tuesday, November 13, 2012 11:30 PM
To: freebsd-embed...@freebsd.org ; freebsd-po...@freebsd.org ;
freebsd-hackers@freebsd.org
Subject: my work on cross-build for mips, arm, etc - your help, please!
I was just going to continuing hacking away at this but adri was really keen
that i post this stuff..
So far with what i’ve got I can cross-build just about anything, but it’s
not automated, there is issues with finding and building dependencies.
i’m using XDEV as the cross compiler
a command line such as
env TARGET=mips TARGET_ARCH=mips make _TARGET_CROSS_DEFS= –C
/usr/ports/net/asterisk10 all
should get the ball rolling
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: my work on cross-build for mips, arm, etc - your help, please!
P.S. some of the ${DESTDIR} things i added can be removed!!!
From: Michael Vale
Sent: Tuesday, November 13, 2012 11:30 PM
To: freebsd-embed...@freebsd.org ; freebsd-po...@freebsd.org ;
freebsd-hackers@freebsd.org
Subject: my work on cross-build for mips, arm, etc - your help, please!
I was just going to continuing hacking away at this but adri was really keen
that i post this stuff..
So far with what i’ve got I can cross-build just about anything, but it’s not
automated, there is issues with finding and building dependencies.
i’m using XDEV as the cross compiler
a command line such as
env TARGET=mips TARGET_ARCH=mips make _TARGET_CROSS_DEFS= –C
/usr/ports/net/asterisk10 all
should get the ball rolling
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
my work on cross-build for mips, arm, etc - your help, please!
I was just going to continuing hacking away at this but adri was really keen that i post this stuff.. So far with what i’ve got I can cross-build just about anything, but it’s not automated, there is issues with finding and building dependencies. i’m using XDEV as the cross compiler a command line such as env TARGET=mips TARGET_ARCH=mips make _TARGET_CROSS_DEFS= –C /usr/ports/net/asterisk10 all should get the ball rolling bsd.cross.mk Description: Binary data bsd.port.mk.diff Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Give users a hint when their locate database is too small.
On Mon, Nov 12, 2012 at 10:07:16PM -0500, Eitan Adler wrote: > What do people think of this? Maybe /usr/libexec/locate.updatedb is a > better pointer? > > commit fb03b777daf2c69bb9612902e38fdb25b256be72 > Author: Eitan Adler > Date: Mon Nov 12 22:05:55 2012 -0500 > > Give users a hint when their locate database is too small. > > Reviwed by: ??? > Approved by: ??? > MFC after:3 weeks > > diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c > index b0faefb..f0c8c37 100644 > --- a/usr.bin/locate/locate/locate.c > +++ b/usr.bin/locate/locate/locate.c > @@ -292,7 +292,7 @@ search_mmap(db, s) > err(1, "`%s'", db); > len = sb.st_size; > if (len < (2*NBG)) > - errx(1, "database too small: %s", db); > + errx(1, "database too small: %s\nTry running > /etc/periodic/weekly/310.locate", db); > > if ((p = mmap((caddr_t)0, (size_t)len, > PROT_READ, MAP_SHARED, > Enlarge your database! ;-) pgpl0X7SYVAfj.pgp Description: PGP signature
Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!)
On Mon, 2012-10-29 at 23:13:00 -0700, hiren panchasara wrote: > Thank you all for the inputs. > I understand this is a long grueling process so I will attempt to do things > in approximately following order: > > 1) prepare a new port for bsd patch > 2) make sure new bsd patch has all options of existing gnu patch > 3) merge outstanding patches: > http://svnweb.freebsd.org/base/head/gnu/usr.bin/patch/?view=log > 4) bug compatibility > 5) performance For 2) and 4) (maybe also 5?) you really should look into ATF and come up with some test cases for each option, someone else also mentioned unit tests that GNU patch ships with? We really would like to see *BSD patch in the base, but it should come with unit tests; it is 2012, after all :) Thanks! Uli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Memory reserves or lack thereof
On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote: > On 11/12/2012 3:48 PM, Konstantin Belousov wrote: > > On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote: > >> This patch still doesn't address the issue of M_NOWAIT calls driving > >> the memory the all the way down to 2 pages, right ? It would be nice to > >> have M_NOWAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE > >> flag to dig deep. > > This is out of scope of the change. But it is required for any further > > adjustements. > > I would suggest a somewhat different response: > > The patch does make M_NOWAIT into a "non-sleep version of M_WAITOK" and > does reintroduce M_USE_RESERVE as a way to specify "dig deep". > > Currently, both M_NOWAIT and M_WAITOK can drive the cache/free memory > down to two pages. The effect of the patch is to stop M_NOWAIT at two > pages rather than allowing it to continue to zero pages. > > When you say, "This is out of scope ...", I believe that you are > referring to changing two pages into something larger. I agree that > this is out of scope for the current change. I referred exactly to the difference between M_USE_RESERVE set or not. IMO this is what was asked by the question author. So yes, my mean of the 'out of scope' is about tweaking the 'two pages reserve' in some way. pgpAl2UTJQyEa.pgp Description: PGP signature
