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]

Date:	Thu, 6 Dec 2007 09:34:32 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Rik van Riel <riel@...hat.com>
Cc:	Daniel Phillips <phillips@...nq.net>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC] [PATCH] A clean approach to writeout throttling

On Thu, 6 Dec 2007 10:52:42 -0500 Rik van Riel <riel@...hat.com> wrote:

> On Thu, 6 Dec 2007 03:55:11 -0800
> Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> > - We a-priori decide to limit a particular stack's peak memory usage to
> >   1MB
> > 
> > - We empirically discover that the maximum amount of memory which is
> >   allocated by that stack on behalf of a single BIO is 16kb.  (ie: that's
> >   the most it has ever used for a single BIO).
> > 
> > - Now, we refuse to feed any more BIOs into the stack when its
> >   instantaneous memory usage exceeds (1MB - 16kb).
> > 
> > Of course, the _average_ memory-per-BIO is much less than 16kb.  So there
> > are a lot of BIOs in flight - probably hundreds, but a minimum of 63.
> 
> There is only one problem I can see with this.  With network block
> IO, some memory will be consumed upon IO completion.  We need to
> make sure we reserve (number of in flight BIOs * maximum amount of
> memory consumed upon IO completion) memory, in addition to the
> memory you're accounting in your example above.
> 

hm, yeah, drat.

What we could do is

- in do_IRQ(): set up a per-cpu pointer to some counter which
  corresponds to this IRQ.

- in the page allocator, if in_irq(), retrieve that per-cpu pointer and
  increment the counter.

- in the network block-io stack we can now look at the number of
  interrupts, number of packets, size of packets and amount of memory
  allocated and work out the max amount of memory which needs to be
  allocated for each frame.

That's all rather handwavy and misses a lot of details and might be
inaccurate too.  Probably sufficient to just work out by hand the amount of
memory which the network stack will need to allocate.  I expect it'll be
two pages..
--
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/