netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	sri@us.ibm.com, mpm@selenic.com, ak@suse.de,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [RFC] Fine-grained memory priorities and PI
Date: Fri, 16 Dec 2005 00:02:48 +1100	[thread overview]
Message-ID: <200512160002.49096.kernel@kolivas.org> (raw)
In-Reply-To: <8803F1D1-E647-45A3-B2A4-E3C95AAC11C6@mac.com>

On Thursday 15 December 2005 23:58, Kyle Moffett wrote:
> On Dec 15, 2005, at 07:45, Con Kolivas wrote:
> > I have some basic process-that-called the memory allocator link in
> > the -ck tree already which alters how aggressively memory is
> > reclaimed according to priority. It does not affect out of memory
> > management but that could be added to said algorithm; however I
> > don't see much point at the moment since oom is still an uncommon
> > condition but regular memory allocation is routine.
>
> My thought would be to generalize the two special cases of writeback
> of dirty pages or dropping of clean pages under memory pressure and
> OOM to be the same general case.  When you are trying to free up
> pages, it may be permissible to drop dirty mbox pages and kill the
> postfix process writing them in order to satisfy allocations for the
> mission-critical database server.  (Or maybe it's the other way
> around).  If a large chunk of the allocated pages have priorities and
> lossless/lossy free functions, then the kernel can be much more
> flexible and configurable about what to do when running low on RAM.

Indeed the implementation I currently have is lightweight to say the least but 
I really didn't think bloating struct page was worth it since the memory cost 
would be prohibitive, but would allow all sorts of priority effects and vm 
scheduling to be possible. That is, struct page could have an extra entry 
keeping track of the highest priority of the process that used it and use 
that to determine further eviction etc.

Cheers,
Con

  reply	other threads:[~2005-12-15 13:02 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-14  9:12 [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism Sridhar Samudrala
2005-12-14  9:22 ` Andi Kleen
2005-12-14 17:55   ` Sridhar Samudrala
2005-12-14 18:41     ` Andi Kleen
2005-12-14 19:20       ` David Stevens
2005-12-15  3:39     ` Matt Mackall
2005-12-15  4:30       ` David S. Miller
2005-12-15  5:02         ` Matt Mackall
2005-12-15  5:23           ` David S. Miller
2005-12-15  5:48             ` Matt Mackall
2005-12-15  5:53             ` Nick Piggin
2005-12-15  5:56             ` Stephen Hemminger
2005-12-15  8:44               ` David Stevens
2005-12-15  8:58                 ` David S. Miller
2005-12-15  9:27                   ` David Stevens
2005-12-15  5:42         ` Andi Kleen
2005-12-15  6:06           ` Stephen Hemminger
2005-12-15  7:37         ` Sridhar Samudrala
2005-12-15  8:21           ` David S. Miller
2005-12-15  8:35             ` Arjan van de Ven
2005-12-15  8:55             ` [RFC] Fine-grained memory priorities and PI Kyle Moffett
2005-12-15  9:04               ` Andi Kleen
2005-12-15 12:51                 ` Kyle Moffett
2005-12-15 13:31                   ` Andi Kleen
2005-12-15 12:45               ` Con Kolivas
2005-12-15 12:58                 ` Kyle Moffett
2005-12-15 13:02                   ` Con Kolivas [this message]
2005-12-16  2:09             ` [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism Sridhar Samudrala
2005-12-16 17:48               ` Stephen Hemminger
2005-12-16 18:38                 ` Sridhar Samudrala
2005-12-21  9:11                   ` Pavel Machek
2005-12-21  9:39                     ` David Stevens
2005-12-14 20:16 ` Jesper Juhl
2005-12-14 20:25   ` Ben Greear
2005-12-14 20:49   ` James Courtier-Dutton
2005-12-14 21:55     ` Sridhar Samudrala
2005-12-14 22:09       ` James Courtier-Dutton
2005-12-14 22:39         ` Ben Greear
2005-12-14 23:42           ` Sridhar Samudrala
2005-12-15  1:54     ` Mitchell Blank Jr
2005-12-15 11:38       ` James Courtier-Dutton
2005-12-15 11:47         ` Arjan van de Ven
2005-12-15 13:00           ` jamal
2005-12-15 13:07             ` Arjan van de Ven
2005-12-15 13:32               ` jamal

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=200512160002.49096.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=ak@suse.de \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=mrmacman_g4@mac.com \
    --cc=netdev@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).