[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160714090934.GB4079@dhcp22.suse.cz>
Date: Thu, 14 Jul 2016 11:09:35 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: Milan Broz <gmazyland@...il.com>,
Ondrej Kozina <okozina@...hat.com>,
Jerome Marchand <jmarchan@...hat.com>,
Stanislav Kozina <skozina@...hat.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
device-mapper development <dm-devel@...hat.com>
Subject: Re: System freezes after OOM
On Wed 13-07-16 11:21:41, Mikulas Patocka wrote:
>
>
> On Wed, 13 Jul 2016, Milan Broz wrote:
>
> > On 07/13/2016 02:50 PM, Michal Hocko wrote:
> > > On Wed 13-07-16 13:10:06, Michal Hocko wrote:
> > >> On Tue 12-07-16 19:44:11, Mikulas Patocka wrote:
> > > [...]
> > >>> As long as swapping is in progress, the free memory is below the limit
> > >>> (because the swapping activity itself consumes any memory over the limit).
> > >>> And that triggered the OOM killer prematurely.
> > >>
> > >> I am not sure I understand the last part. Are you saing that we trigger
> > >> OOM because the initiated swapout will not be able to finish the IO thus
> > >> release the page in time?
> > >>
> > >> The oom detection checks waits for an ongoing writeout if there is no
> > >> reclaim progress and at least half of the reclaimable memory is either
> > >> dirty or under writeback. Pages under swaout are marked as under
> > >> writeback AFAIR. The writeout path (dm-crypt worker in this case) should
> > >> be able to allocate a memory from the mempool, hand over to the crypt
> > >> layer and finish the IO. Is it possible this might take a lot of time?
> > >
> > > I am not familiar with the crypto API but from what I understood from
> > > crypt_convert the encryption is done asynchronously. Then I got lost in
> > > the indirection. Who is completing the request and from what kind of
> > > context? Is it possible it wouldn't be runable for a long time?
> >
> > If you mean crypt_convert in dm-crypt, then it can do asynchronous completion
> > but usually (with AES-NI ans sw implementations) it run the operation completely
> > synchronously.
> > Asynchronous processing is quite rare, usually only on some specific hardware
> > crypto accelerators.
> >
> > Once the encryption is finished, the cloned bio is sent to the block
> > layer for processing.
> > (There is also some magic with sorting writes but Mikulas knows this better.)
>
> dm-crypt receives requests in crypt_map, then it distributes write
> requests to multiple encryption threads. Encryption is done usually
> synchronously; asynchronous completion is used only when using some PCI
> cards that accelerate encryption. When encryption finishes, the encrypted
> pages are submitted to a thread dmcrypt_write that sorts the requests
> using rbtree and submits them.
OK. I was worried that the async context would depend on WQ and a lack
of workers could lead to long stalls. Dedicated kernel threads seem
sufficient.
Thanks for the clarification.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists