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. The block layer has a deficiency that it cannot merge adjacent requests submitted by the different threads. If we submitted requests directly from encryption threads, lack of merging degraded performance seriously. Mikulas > Milan > p.s. I added cc to dm-devel, some dmcrypt people reads only this list. > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
