linux-kernel - Re: [RFC] [PATCH] A clean approach to writeout throttling

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: <20071206122701.85627fb4.akpm@linux-foundation.org>
Date:	Thu, 6 Dec 2007 12:27:01 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	linux-kernel@...r.kernel.org, peterz@...radead.org
Subject: Re: [RFC] [PATCH] A clean approach to writeout throttling

On Thu, 6 Dec 2007 12:04:14 -0800
Daniel Phillips <phillips@...nq.net> wrote:

> Any idea 
> how to extend the accounting idea to all tasks involved in a particular 
> block device stack?

SMOP, I'd have thought.  As long as each piece of code which handles data
for this stack knows that it's handling data for that stack it should be
able to account its memory allocations.

The tricky part will be networking allocations because a NIC can of course
handle data for all sorts of consumers.  But I expect this can be greatly
simplified with a few heuristics - work out how much memory your typical
networking stack will allocate for a frame and tack that onto the total.
Couple of pages worst case..
--
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/