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, 7 Feb 2007 10:39:04 -0800 From: "Nate Diller" <nate.diller@...il.com> To: "Christoph Lameter" <clameter@....com> Cc: "Arjan van de Ven" <arjan@...radead.org>, "Andrew Morton" <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org, "Nick Piggin" <nickpiggin@...oo.com.au>, "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@...fujitsu.com>, "Rik van Riel" <riel@...hat.com> Subject: Re: [RFC] Tracking mlocked pages and moving them off the LRU On 2/7/07, Christoph Lameter <clameter@....com> wrote: > On Tue, 6 Feb 2007, Nate Diller wrote: > > > > The dirty ratio with the ZVCS would be > > > > > > NR_DIRTY + NR_UNSTABLE_NFS > > > / > > > NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE + NR_MLOCK > > > > I don't understand why you want to account mlocked pages in > > dirty_ratio. of course mlocked pages *can* be dirty, but they have no > > relevance in the write throttling code. the point of dirty ratio is > > mlocked pages can be counted as dirty pages. So if we do not include > NR_MLOCK in the number of total pages that could be dirty then we may in > some cases have >100% dirty pages. unless we exclude mlocked dirty pages from NR_DIRTY accounting, which is what i suggest should be done as part of this patch > > to guarantee that there are some number of non-dirty, non-pinned, > > non-mlocked pages on the LRU, to (try to) avoid deadlocks where the > > writeback path needs to allocate pages, which many filesystems like to > > do. if an mlocked page is clean, there's still no way to free it up, > > so it should not be treated as being on the LRU at all, for write > > throttling. the ideal (IMO) dirty ratio would be > > Hmmm... I think write throttling is different from reclaim. In write > throttling the major objective is to decouple the applications from > the physical I/O. So the dirty ratio specifies how much "buffer" space > can be used for I/O. There is an issue that too many dirty pages will > cause difficulty for reclaim because pages can only be reclaimed after > writeback is complete. NR_DIRTY is only used for write throttling, right? well, and reporting to user-space, but again, i suggest that user space should get to see NR_MLOCKED as well. would people flip out if NR_DIRTY stopped showing pages that are mlocked, as long as a seperate NR_MLOCKED variable was present? > And yes this is not true for mlocked pages. > > > > > NR_DIRTY - NR_DIRTY_MLOCKED + NR_UNSTABLE_NFS > > / > > NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE > > > > obviously it's kinda useless to keep an NR_DIRTY_MLOCKED counter, any > > of these mlock accounting schemes could easily be modified to update > > the NR_DIRTY counter so that it only reflects dirty unpinned pages, > > and not mlocked ones. > > So you would be okay with dirty_ratio possibly be >100% of mlocked pages > are dirty? > > > is that the only place you wanted to have an accurate mocked page count? > > Rik had some other ideas on what to do with it. I also think we may end up > checking for excessive high mlock counts in various tight VM situations. i'd be wary of a VM algorithm that treated mlocked pages any differently than, say, unreclaimable slab pages. but there are no concrete suggestions yet, so i won't comment further. all this is not to say that i dislike the idea of keeping mlocked pages off the LRU, quite the opposite i've been looking for this for a while and was hoping that Stone Wang's wired list patch (http://lkml.org/lkml/2006/3/20/128) would get further than it did. but i don't see the need to keep strict accounting if it hurts performance in the common case. NATE - 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