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
| ||
|
Date: Wed, 21 Apr 2010 09:19:08 -0400 From: Rik van Riel <riel@...hat.com> To: Christian Ehrhardt <ehrhardt@...ux.vnet.ibm.com> CC: Johannes Weiner <hannes@...xchg.org>, Mel Gorman <mel@....ul.ie>, Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org, Nick Piggin <npiggin@...e.de>, Chris Mason <chris.mason@...cle.com>, Jens Axboe <jens.axboe@...cle.com>, linux-kernel@...r.kernel.org, gregkh@...ell.com, Corrado Zoccolo <czoccolo@...il.com> Subject: Re: [RFC PATCH 0/3] Avoid the use of congestion_wait under zone pressure On 04/21/2010 03:35 AM, Christian Ehrhardt wrote: > > > Christian Ehrhardt wrote: >> >> >> Rik van Riel wrote: >>> On 04/20/2010 11:32 AM, Johannes Weiner wrote: >>> >>>> The idea is that it pans out on its own. If the workload changes, new >>>> pages get activated and when that set grows too large, we start >>>> shrinking >>>> it again. >>>> >>>> Of course, right now this unscanned set is way too large and we can end >>>> up wasting up to 50% of usable page cache on false active pages. >>> >>> Thing is, changing workloads often change back. >>> >>> Specifically, think of a desktop system that is doing >>> work for the user during the day and gets backed up >>> at night. >>> >>> You do not want the backup to kick the working set >>> out of memory, because when the user returns in the >>> morning the desktop should come back quickly after >>> the screensaver is unlocked. >> >> IMHO it is fine to prevent that nightly backup job from not being >> finished when the user arrives at morning because we didn't give him >> some more cache - and e.g. a 30 sec transition from/to both optimized >> states is fine. >> But eventually I guess the point is that both behaviors are reasonable >> to achieve - depending on the users needs. >> >> What we could do is combine all our thoughts we had so far: >> a) Rik could create an experimental patch that excludes the in flight >> pages >> b) Johannes could create one for his suggestion to "always scan active >> file pages but only deactivate them when the ratio is off and >> otherwise strip buffers of clean pages" I think you are confusing "buffer heads" with "buffers". You can strip buffer heads off pages, but that is not your problem. "buffers" in /proc/meminfo stands for cached metadata, eg. the filesystem journal, inodes, directories, etc... Caching such metadata is legitimate, because it reduces the number of disk seeks down the line. -- 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