lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.00.1001272300120.2909@abydos.NerdBox.Net>
Date:	Wed, 27 Jan 2010 23:16:49 -0800 (PST)
From:	Steve VanDeBogart <vandebo-lkml@...dBox.Net>
To:	Minchan Kim <minchan.kim@...il.com>
cc:	Wu Fengguang <fengguang.wu@...el.com>,
	Chris Frost <frost@...ucla.edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Steve Dickson <steved@...hat.com>,
	David Howells <dhowells@...hat.com>,
	Xu Chenfeng <xcf@...c.edu.cn>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/readahead.c: update the LRU positions of in-core
 pages, too

On Wed, 27 Jan 2010, Minchan Kim wrote:

> This patch effect happens when inactive file list is small, I think.
> It means it's high memory pressure. so if we move ra pages into

This patch does the same thing regardless of memory pressure - it
doesn't just apply in high memory pressure situations.  Is your concern
that in high memory pressure situations this patch with make things worse?

> head of inactive list, other application which require free page urgently
> suffer from latency or are killed.

I don't think this patch will affect the number of pages reclaimed, only
which pages are reclaimed.  In extreme cases it could increase the time
needed to reclaim that many pages, but the inactive list would have to be
very short.

> If VM don't have this patch, of course ra pages are discarded and
> then I/O performance would be bad. but as I mentioned, it's time
> high memory pressure. so I/O performance low makes system
> natural throttling. It can help out of  system memory pressure.

Even in low memory situations, improving I/O performance can help the
overall system performance.  For example if most of the inactive list 
is dirty, needlessly discarding pages, just to refetch them will clog
I/O and increase the time needed to write out the dirty pages.

> In summary I think it's good about viewpoint of I/O but I am not sure
> it's good about viewpoint of system.

In this case, I think what's good for I/O is good for the system.
Please help me understand if I am missing something.  Thanks

--
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ