linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
To: Andrea Arcangeli <arcangeli@mbox.queen.it>
Cc: Linux MM <linux-mm@kvack.org>,
	Linux Kernel <linux-kernel@vger.rutgers.edu>
Subject: Re: cp file /dev/zero <-> cache [was Re: increasing page size]
Date: Sun, 5 Jul 1998 19:00:04 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.3.96.980705185219.1574D-100000@mirkwood.dummy.home> (raw)
In-Reply-To: <Pine.LNX.3.96.980705131034.327C-100000@dragon.bogus>

On Sun, 5 Jul 1998, Andrea Arcangeli wrote:
> On Sun, 5 Jul 1998, Rik van Riel wrote:
> 
> >We can achieve this by switching off readahead when we
> >reach the maximum RSS of the inode. Then we should probably
> 
> I run hdparm -a0 /dev/hda and nothing change. Now the cache take 20Mbyte
> of memory running cp file /dev/null while memtest 10000000 is running.

Hdparm only affects _hardware_ readahead and has nothing
to do with software readahead.

> >instruct kswapd in some way to remove pages from that inode,
> >but I'm not completely sure how to do that...
> 
> Where does the cache is allocated? Is it allocated in the inode? If so
> kswapd should shrink the inode before start swapping out! 

The cache is also mapped into a process'es address space.
Currently we would have to walk all pagetables to find a
specific page ;(
When Stephen and Ben have merged their PTE stuff, we can
do the freeing much easier though...

> >For the buffer cache, we might be able to use the same
> >kind of algorithm, but I'm not completely sure of that.
> 
> The buffer memory seems to be reduced better than the cache memory though.

This is partly because buffer memory is not mapped in any
pagetable and because buffer memory generally isn't worth
keeping around. Because of that we can and do just throw
it out on the next opportunity.

> >Both can be avoided by using (not yet implemented)
> >balancing code. It is on the priority list of the MM
> I had to ask "2.0.34 has balancing code implemented and running?". The

2.0 has no balancing code at all. At least, not AFAIK...

> current mm layer is not able to shrink the cache memory and I consider it
> a bug that must be fixed without adding other code. 

How do you propose we solve a bug without programming :)

> Is there a function call (such us shrink_mmap for mmap or
> kmem_cache_reap() for slab or shrink_dcache_memory() for dcache) that is
> able to shrink the cache allocated by cp file /dev/zero?

shrink_mmap() can only shrink unlocked and clean buffer pages
and unmapped cache pages. We need to go through either bdflush
(for buffer) or try_to_swap_out() first, in order to make some
easy victims for shrink_mmap()...

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

  reply	other threads:[~1998-07-05 18:07 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.3.96.980705072829.17879D-100000@mirkwood.dummy.home>
1998-07-05 11:32 ` Andrea Arcangeli
1998-07-05 17:00   ` Rik van Riel [this message]
1998-07-05 18:38     ` Andrea Arcangeli
1998-07-05 19:31       ` Rik van Riel
1998-07-06 10:38         ` Stephen C. Tweedie
1998-07-06 11:42           ` Rik van Riel
1998-07-06 14:20         ` Andrea Arcangeli
1998-07-06 10:31       ` Stephen C. Tweedie
1998-07-06 12:34         ` Andrea Arcangeli
1998-07-06 14:36           ` Stephen C. Tweedie
1998-07-06 19:28             ` Andrea Arcangeli
1998-07-07 12:01               ` Stephen C. Tweedie
1998-07-07 15:54                 ` Rik van Riel
1998-07-07 17:32                   ` Benjamin C.R. LaHaise
1998-07-08 13:54                     ` Stephen C. Tweedie
1998-07-08 21:19                       ` Andrea Arcangeli
1998-07-11 11:18                         ` Rik van Riel
1998-07-11 21:11                           ` Stephen C. Tweedie
1998-07-08 13:45                   ` Stephen C. Tweedie
1998-07-08 18:57                     ` Rik van Riel
1998-07-08 22:11                       ` Stephen C. Tweedie
1998-07-09  7:43                         ` Rik van Riel
1998-07-09 20:39                         ` Rik van Riel
1998-07-13 11:54                           ` Stephen C. Tweedie
1998-07-05 18:57     ` MOLNAR Ingo
1998-07-06 10:24     ` Stephen C. Tweedie
1998-07-06 13:37       ` Eric W. Biederman
1998-07-07 12:35         ` Stephen C. Tweedie
1998-07-09 13:01 Zachary Amsden
     [not found] <199807091442.PAA01020@dax.dcs.ed.ac.uk>
1998-07-09 18:59 ` Rik van Riel
1998-07-09 23:37   ` Stephen C. Tweedie
1998-07-10  5:57     ` Rik van Riel
1998-07-11 14:14 ` Rik van Riel
1998-07-11 21:23   ` Stephen C. Tweedie
1998-07-11 22:25     ` Rik van Riel
1998-07-13 13:23       ` Stephen C. Tweedie
1998-07-12  1:47     ` Benjamin C.R. LaHaise
1998-07-13 13:42       ` Stephen C. Tweedie
1998-07-18 22:10         ` Rik van Riel
1998-07-20 16:04           ` Stephen C. Tweedie

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=Pine.LNX.3.96.980705185219.1574D-100000@mirkwood.dummy.home \
    --to=h.h.vanriel@phys.uu.nl \
    --cc=arcangeli@mbox.queen.it \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    /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