From: Sridhar Samudrala <sri@us.ibm.com>
To: Matthew Dobson <colpatch@us.ibm.com>
Cc: Pavel Machek <pavel@suse.cz>,
linux-kernel@vger.kernel.org, andrea@suse.de,
Andrew Morton <akpm@osdl.org>,
Linux Memory Management <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH 0/6] Critical Page Pool
Date: Thu, 15 Dec 2005 21:02:39 -0800 [thread overview]
Message-ID: <43A24A6F.5090907@us.ibm.com> (raw)
In-Reply-To: <43A1E551.1090403@us.ibm.com>
Matthew Dobson wrote:
>Pavel Machek wrote:
>
>
>>>>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.
>>>
>>>
>>Perhaps you should add file in Documentation/ explaining it is not
>>reliable?
>>
>>
>
>That's a good suggestion. I will rework the patch's additions to
>Documentation/sysctl/vm.txt to be more clear about exactly what we're
>providing.
>
>
>
>
>>>>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.
>>>
>>>
>>Well, we don't usually take infrastructure that has no in-kernel
>>users, and example user would indeed be nice.
>> Pavel
>>
>>
>
>Understood. I certainly wouldn't expect otherwise. I'll see if I can get
>Sridhar to post his networking changes that take advantage of this.
>
>
I have posted these patches yesterday on lkml and netdev and here is a
link to the thread.
http://thread.gmane.org/gmane.linux.kernel/357835
Thanks
Sridhar
WARNING: multiple messages have this Message-ID (diff)
From: Sridhar Samudrala <sri@us.ibm.com>
To: Matthew Dobson <colpatch@us.ibm.com>
Cc: Pavel Machek <pavel@suse.cz>,
linux-kernel@vger.kernel.org, andrea@suse.de,
Andrew Morton <akpm@osdl.org>,
Linux Memory Management <linux-mm@kvack.org>
Subject: Re: [RFC][PATCH 0/6] Critical Page Pool
Date: Thu, 15 Dec 2005 21:02:39 -0800 [thread overview]
Message-ID: <43A24A6F.5090907@us.ibm.com> (raw)
In-Reply-To: <43A1E551.1090403@us.ibm.com>
Matthew Dobson wrote:
>Pavel Machek wrote:
>
>
>>>>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.
>>>
>>>
>>Perhaps you should add file in Documentation/ explaining it is not
>>reliable?
>>
>>
>
>That's a good suggestion. I will rework the patch's additions to
>Documentation/sysctl/vm.txt to be more clear about exactly what we're
>providing.
>
>
>
>
>>>>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.
>>>
>>>
>>Well, we don't usually take infrastructure that has no in-kernel
>>users, and example user would indeed be nice.
>> Pavel
>>
>>
>
>Understood. I certainly wouldn't expect otherwise. I'll see if I can get
>Sridhar to post his networking changes that take advantage of this.
>
>
I have posted these patches yesterday on lkml and netdev and here is a
link to the thread.
http://thread.gmane.org/gmane.linux.kernel/357835
Thanks
Sridhar
--
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-16 5:03 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
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 [this message]
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=43A24A6F.5090907@us.ibm.com \
--to=sri@us.ibm.com \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=colpatch@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pavel@suse.cz \
/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.