linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: akpm@osdl.org
Cc: tony.luck@intel.com, linux-ia64@vger.kernel.org, linux-mm@kvack.org
Subject: ia64 needs to shake memory from quicklists when there is memory pressure.
Date: Wed, 9 Mar 2005 11:09:15 -0600	[thread overview]
Message-ID: <20050309170915.GA1583@lnx-holt.americas.sgi.com> (raw)

Andrew,

I am searching for some direction.  I am in the process of pushing
changes to the ia64 page table cache (quicklist) code.  One result of
the changes is I end up changing the algorithm for freeing pages from
the quicklist being based on a boot-time calculation of a percentage of
total system memory to a percentage of memory free on the node (whole
system for non-numa) at the time the shrink call is made.

Right now, there are two places that the shrink is invoked.  One is
from the tlb_finish_mmu() code which would be immediately after the only
place that items are added to the list.  The other is from cpu_idle which
appears to be a carry over from when x86 code was pulled over to ia64.
The purpose for that appears to have been making the sysctl (which has
been removed) take effect in situations where a cpu is never calling
tlb_finish_mmu().

The "ideal" would be to have a node aware slab cache.  Since that
is probably a long time coming, I was wondering if there would be
any possibility of getting some sort of hook into wakeup_kswapd(),
kswapd(), or balance_pgdat().  Since the quicklists are maintained per
cpu, we would need to perform an smp_call_function_single() for other
cpus on this node.  Is there some mechanism in place already to handle
anything similar to this?  Is there a better way to accomplish this?
Can you offer any suggestions?

Thanks,
Robin Holt

PS:  Some relevant links.
Discuss the shrink issues:
http://marc.theaimsgroup.com/?l=linux-ia64&m=110990848315823&w=2

The code change to do the free.
http://marc.theaimsgroup.com/?l=linux-ia64&m=110978917715909&w=2
--
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:"aart@kvack.org"> aart@kvack.org </a>

             reply	other threads:[~2005-03-09 17:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-09 17:09 Robin Holt [this message]
2005-03-09 17:15 ` Martin J. Bligh
2005-03-14 16:24   ` Robin Holt
2005-03-14 16:37     ` Martin J. Bligh
2005-03-09 19:32 ` Andrew Morton
2005-03-14 16:40   ` Robin Holt
2005-03-14 21:39     ` Andrew Morton

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=20050309170915.GA1583@lnx-holt.americas.sgi.com \
    --to=holt@sgi.com \
    --cc=akpm@osdl.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tony.luck@intel.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