From: Matthew Dobson <colpatch@us.ibm.com>
To: Pavel Machek <pavel@suse.cz>
Cc: linux-kernel@vger.kernel.org, andrea@suse.de,
Sridhar Samudrala <sri@us.ibm.com>, Andrew Morton <akpm@osdl.org>,
Linux Memory Management <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH 0/6] Critical Page Pool
Date: Wed, 14 Dec 2005 07:55:24 -0800 [thread overview]
Message-ID: <43A0406C.8020108@us.ibm.com> (raw)
In-Reply-To: <20051214100841.GA18381@elf.ucw.cz>
Pavel Machek wrote:
> Hi!
>
>
>>The overall purpose of this patch series is to all a system administrator
>>to reserve a number of pages in a 'critical pool' that is set aside for
>>situations when the system is 'in emergency'. It is up to the individual
>>administrator to determine when his/her system is 'in emergency'. This is
>>not meant to (necessarily) anticipate OOM situations, though that is
>>certainly one possible use. The purpose this was originally designed for
>>is to allow the networking code to keep functioning despite the sytem
>>losing its (potentially networked) swap device, and thus temporarily
>>putting the system under exreme memory pressure.
>
>
> I don't see how this can ever work.
>
> How can _userspace_ know about what allocations are critical to the
> kernel?!
Well, it isn't userspace that is determining *which* allocations are
critical to the kernel. That is statically determined at compile time by
using the flag __GFP_CRITICAL on specific *kernel* allocations. Sridhar,
cc'd on this mail, has a set of patches that sprinkle the __GFP_CRITICAL
flag throughout the networking code to take advantage of this pool.
Userspace is in charge of determining *when* we're in an emergency
situation, and should thus use the critical pool, but not *which*
allocations are critical to surviving this emergency situation.
> And as you noticed, it does not work for your original usage case,
> because reserved memory pool would have to be "sum of all network
> interface bandwidths * ammount of time expected to survive without
> network" which is way too much.
Well, I never suggested it didn't work for my original usage case. The
discussion we had is that it would be incredibly difficult to 100%
iron-clad guarantee that the pool would NEVER run out of pages. But we can
size the pool, especially given a decent workload approximation, so as to
make failure far less likely.
> If you want few emergency pages for some strange hack you are doing
> (swapping over network?), just put swap into ramdisk and swapon() it
> when you are in emergency, or use memory hotplug and plug few more
> gigabytes into your machine. But don't go introducing infrastructure
> that _can't_ be used right.
Well, that's basically the point of posting these patches as an RFC. I'm
not quite so delusional as to think they're going to get picked up right
now. I was, however, hoping for feedback to figure out how to design
infrastructure that *can* be used right, as well as trying to find other
potential users of such a feature.
Thanks!
-Matt
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Dobson <colpatch@us.ibm.com>
To: Pavel Machek <pavel@suse.cz>
Cc: linux-kernel@vger.kernel.org, andrea@suse.de,
Sridhar Samudrala <sri@us.ibm.com>, Andrew Morton <akpm@osdl.org>,
Linux Memory Management <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH 0/6] Critical Page Pool
Date: Wed, 14 Dec 2005 07:55:24 -0800 [thread overview]
Message-ID: <43A0406C.8020108@us.ibm.com> (raw)
In-Reply-To: <20051214100841.GA18381@elf.ucw.cz>
Pavel Machek wrote:
> Hi!
>
>
>>The overall purpose of this patch series is to all a system administrator
>>to reserve a number of pages in a 'critical pool' that is set aside for
>>situations when the system is 'in emergency'. It is up to the individual
>>administrator to determine when his/her system is 'in emergency'. This is
>>not meant to (necessarily) anticipate OOM situations, though that is
>>certainly one possible use. The purpose this was originally designed for
>>is to allow the networking code to keep functioning despite the sytem
>>losing its (potentially networked) swap device, and thus temporarily
>>putting the system under exreme memory pressure.
>
>
> I don't see how this can ever work.
>
> How can _userspace_ know about what allocations are critical to the
> kernel?!
Well, it isn't userspace that is determining *which* allocations are
critical to the kernel. That is statically determined at compile time by
using the flag __GFP_CRITICAL on specific *kernel* allocations. Sridhar,
cc'd on this mail, has a set of patches that sprinkle the __GFP_CRITICAL
flag throughout the networking code to take advantage of this pool.
Userspace is in charge of determining *when* we're in an emergency
situation, and should thus use the critical pool, but not *which*
allocations are critical to surviving this emergency situation.
> And as you noticed, it does not work for your original usage case,
> because reserved memory pool would have to be "sum of all network
> interface bandwidths * ammount of time expected to survive without
> network" which is way too much.
Well, I never suggested it didn't work for my original usage case. The
discussion we had is that it would be incredibly difficult to 100%
iron-clad guarantee that the pool would NEVER run out of pages. But we can
size the pool, especially given a decent workload approximation, so as to
make failure far less likely.
> If you want few emergency pages for some strange hack you are doing
> (swapping over network?), just put swap into ramdisk and swapon() it
> when you are in emergency, or use memory hotplug and plug few more
> gigabytes into your machine. But don't go introducing infrastructure
> that _can't_ be used right.
Well, that's basically the point of posting these patches as an RFC. I'm
not quite so delusional as to think they're going to get picked up right
now. I was, however, hoping for feedback to figure out how to design
infrastructure that *can* be used right, as well as trying to find other
potential users of such a feature.
Thanks!
-Matt
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-12-14 15:55 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-14 7:50 [RFC][PATCH 0/6] Critical Page Pool Matthew Dobson
2005-12-14 7:50 ` Matthew Dobson
2005-12-14 7:52 ` [RFC][PATCH 1/6] Create " Matthew Dobson
2005-12-14 10:48 ` Andrea Arcangeli
2005-12-14 10:48 ` Andrea Arcangeli
2005-12-14 13:30 ` Rik van Riel
2005-12-14 13:30 ` Rik van Riel
2005-12-14 16:26 ` Matthew Dobson
2005-12-14 16:26 ` Matthew Dobson
2005-12-15 3:29 ` Matt Mackall
2005-12-15 3:29 ` Matt Mackall
2005-12-14 7:54 ` [RFC][PATCH 2/6] in_emergency Trigger Matthew Dobson
2005-12-14 7:56 ` [RFC][PATCH 3/6] Slab Prep: get/return_object Matthew Dobson
2005-12-14 8:19 ` Pekka Enberg
2005-12-14 8:19 ` Pekka Enberg
2005-12-14 16:26 ` Matthew Dobson
2005-12-14 16:26 ` Matthew Dobson
2005-12-14 7:58 ` [RFC][PATCH 4/6] Slab Prep: slab_destruct() Matthew Dobson
2005-12-14 8:37 ` Pekka Enberg
2005-12-14 8:37 ` Pekka Enberg
2005-12-14 16:30 ` Matthew Dobson
2005-12-14 16:30 ` Matthew Dobson
2005-12-14 7:59 ` [RFC][PATCH 5/6] Slab Prep: Move cache_grow() Matthew Dobson
2005-12-14 8:02 ` [RFC][PATCH 6/6] Critical Page Pool: Slab Support Matthew Dobson
2005-12-14 10:08 ` [RFC][PATCH 0/6] Critical Page Pool Pavel Machek
2005-12-14 10:08 ` Pavel Machek
2005-12-14 12:01 ` Andrea Arcangeli
2005-12-14 12:01 ` Andrea Arcangeli
2005-12-14 13:03 ` Alan Cox
2005-12-14 13:03 ` Alan Cox
2005-12-14 16:37 ` Matthew Dobson
2005-12-14 16:37 ` Matthew Dobson
2005-12-14 19:17 ` Alan Cox
2005-12-14 19:17 ` Alan Cox
2005-12-15 16:27 ` Pavel Machek
2005-12-15 16:27 ` Pavel Machek
2005-12-14 16:03 ` Matthew Dobson
2005-12-14 16:03 ` Matthew Dobson
2005-12-14 15:55 ` Matthew Dobson [this message]
2005-12-14 15:55 ` Matthew Dobson
2005-12-15 16:26 ` Pavel Machek
2005-12-15 16:26 ` Pavel Machek
2005-12-15 21:51 ` Matthew Dobson
2005-12-15 21:51 ` Matthew Dobson
2005-12-16 5:02 ` Sridhar Samudrala
2005-12-16 5:02 ` Sridhar Samudrala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43A0406C.8020108@us.ibm.com \
--to=colpatch@us.ibm.com \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pavel@suse.cz \
--cc=sri@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.