linux-kernel - Re: [PATCH -mm] vmscan: make mapped executable pages the first class citizen

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]

Date:	Sun, 10 May 2009 21:13:50 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Rik van Riel <riel@...hat.com>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Wu Fengguang <fengguang.wu@...el.com>, hannes@...xchg.org,
	linux-kernel@...r.kernel.org, tytso@....edu, linux-mm@...ck.org,
	elladan@...imo.com, npiggin@...e.de, cl@...ux-foundation.org,
	minchan.kim@...il.com
Subject: Re: [PATCH -mm] vmscan: make mapped executable pages the first
 class  citizen

> > Not only can it be abused but some systems such as java have large
> > PROT_EXEC mapped environments, as do many other JIT based languages.
> 
> On the file LRU side, or on the anon LRU side?

Generally anonymous so it would indeed be ok.

> > I still think the focus is on the wrong thing. We shouldn't be trying to
> > micro-optimise page replacement guesswork - we should be macro-optimising
> > the resulting I/O performance.
> 
> Any ideas on how to achieve that? :)

I know - vm is hard, and page out consists of making the best wrong
decision without having the facts.

Make your swap decisions depend upon I/O load on storage devices. Make
your paging decisions based upon writing and reading large contiguous
chunks (512K costs the same as 8K pretty much) - but you already know
that .

Historically BSD tackled some of this by actually swapping processes out
once pressure got very high - because even way back it actually became
cheaper at some point than spewing randomness at the disk drive. Plus it
also avoids the death by thrashing problem. Possibly however that means
the chunk size should relate to the paging rate ?

I get to watch what comes down the pipe from the vm, and it's not pretty,
especially when todays disk drive is more like swapping to a tape loop. I
can see how to fix anonymous page out (log structured swap) but I'm not
sure what that would do to anonymous page-in even with a cleaner.

At the block level it may be worth having a look what is going on in more
detail - the bigger queues and I/O sizes on modern disks (plus the
cache flushimng) also mean that the amount of time it can take a command
to the head and back to the OS has probably jumped a lot with newer SATA
devices - even if the block layer is getting them queued at the head of
the queue and promptly. I can give a disk 15 seconds of work quite easily
and possibly stuffing the disk stupid isn't the right algorithm when
paging is considered.

rpm -e gnome* and Arjan's ioprio hacks seem to fix my box but thats not a
general useful approach. I need to re-test the ioprio hacks with a
current kernel and see if the other I/O changes have helped.

Alan
--
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/