linux-kernel - Re: [Xen-devel] [PATCH 0/2] xen/blkback: Aggressively shrink page pools if a memory pressure is detected

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] [day] [month] [year] [list]

Message-ID: <fcf414ab-4ee4-bafc-6683-5527df7a9731@amazon.com>
Date:   Wed, 4 Dec 2019 13:09:13 +0100
From:   <sjpark@...zon.com>
To:     "Durrant, Paul" <pdurrant@...zon.com>,
        "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
        "roger.pau@...rix.com" <roger.pau@...rix.com>,
        "axboe@...nel.dk" <axboe@...nel.dk>
CC:     "sj38.park@...il.com" <sj38.park@...il.com>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 0/2] xen/blkback: Aggressively shrink page
 pools if a memory pressure is detected

On 04.12.19 12:52, Durrant, Paul wrote:
>> -----Original Message-----
>> From: Xen-devel <xen-devel-bounces@...ts.xenproject.org> On Behalf Of
>> SeongJae Park
>> Sent: 04 December 2019 11:34
>> To: konrad.wilk@...cle.com; roger.pau@...rix.com; axboe@...nel.dk
>> Cc: sj38.park@...il.com; xen-devel@...ts.xenproject.org; linux-
>> block@...r.kernel.org; linux-kernel@...r.kernel.org; Park, Seongjae
>> <sjpark@...zon.com>
>> Subject: [Xen-devel] [PATCH 0/2] xen/blkback: Aggressively shrink page
>> pools if a memory pressure is detected
>>
>> Each `blkif` has a free pages pool for the grant mapping.  The size of
>> the pool starts from zero and be increased on demand while processing
>> the I/O requests.  If current I/O requests handling is finished or 100
>> milliseconds has passed since last I/O requests handling, it checks and
>> shrinks the pool to not exceed the size limit, `max_buffer_pages`.
>>
>> Therefore, `blkfront` running guests can cause a memory pressure in the
>> `blkback` running guest by attaching arbitrarily large number of block
>> devices and inducing I/O.
> OOI... How do guests unilaterally cause the attachment of arbitrary numbers of PV devices?
Good point.  Many systems have their limit for the maximum number of the
devices.  Thus, 'arbitrarily' large number of devices cannot be attached.  So,
there is the upperbound.  System administrators might be able to avoid the
memory pressure problem by setting the limit low enough or giving more memory
to the 'blkback' running guest.

However, many systems also tempt to set the limit high enough so that guests
can satisfy and to give minimal memory to the 'blkback' running guest for cost
efficiency.

I believe this patchset can be helpful for such situations.

Anyway, using the term 'arbitrarily' is obvisously my fault.  I will update the
description in the next version of patchset.


Thanks,
SeongJae Park

>
>   Paul
>