From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758613AbcG0VgY (ORCPT ); Wed, 27 Jul 2016 17:36:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:45211 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758308AbcG0VgX (ORCPT ); Wed, 27 Jul 2016 17:36:23 -0400 From: NeilBrown To: Mikulas Patocka Date: Thu, 28 Jul 2016 07:36:12 +1000 Cc: Tetsuo Handa , LKML , Michal Hocko , linux-mm@kvack.org, dm-devel@redhat.com, Mel Gorman , David Rientjes , Ondrej Kozina , Andrew Morton Subject: Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks In-Reply-To: References: <1468831164-26621-1-git-send-email-mhocko@kernel.org> <1468831285-27242-1-git-send-email-mhocko@kernel.org> <1468831285-27242-2-git-send-email-mhocko@kernel.org> <87oa5q5abi.fsf@notabene.neil.brown.name> <20160722091558.GF794@dhcp22.suse.cz> <878twt5i1j.fsf@notabene.neil.brown.name> <87invr4tjm.fsf@notabene.neil.brown.name> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-suse-linux-gnu) Message-ID: <87bn1i4vcj.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, Jul 28 2016, Mikulas Patocka wrote: > On Wed, 27 Jul 2016, NeilBrown wrote: > >> On Tue, Jul 26 2016, Mikulas Patocka wrote: >>=20 >> > On Sat, 23 Jul 2016, NeilBrown wrote: >> > >> >> "dirtying ... from the reclaim context" ??? What does that mean? >> >> According to >> >> Commit: 26eecbf3543b ("[PATCH] vm: pageout throttling") >> >> From the history tree, the purpose of throttle_vm_writeout() is to >> >> limit the amount of memory that is concurrently under I/O. >> >> That seems strange to me because I thought it was the responsibility = of >> >> each backing device to impose a limit - a maximum queue size of some >> >> sort. >> > >> > Device mapper doesn't impose any limit for in-flight bios. >>=20 >> I would suggest that it probably should. At least it should >> "set_wb_congested()" when the number of in-flight bios reaches some >> arbitrary threshold. > > If we set the device mapper device as congested, it can again trigger tha= t=20 > mempool alloc throttling bug. > > I.e. suppose that we swap to a dm-crypt device. The dm-crypt device=20 > becomes clogged and sets its state as congested. The underlying block=20 > device is not congested. > > The mempool_alloc function in the dm-crypt workqueue sets the=20 > PF_LESS_THROTTLE flag, and tries to allocate memory, but according to=20 > Michal's patches, processes with PF_LESS_THROTTLE may still get throttled. > > So if we set the dm-crypt device as congested, it can incorrectly throttl= e=20 > the dm-crypt workqueue that does allocations of temporary pages and=20 > encryption. > > I think that approach with PF_LESS_THROTTLE in mempool_alloc is incorrect= =20 > and that mempool allocations should never be throttled. I very much agree with that last statement! It may be that to get to that point we will need all backing devices to signal congestion correctly. > >> > I've made some patches that limit in-flight bios for device mapper in >> > the past, but there were not integrated into upstream. >>=20 >> I second the motion to resurrect these. > > I uploaded those patches here: > > http://people.redhat.com/~mpatocka/patches/kernel/dm-limit-outstanding-bi= os/ Thanks! I'll have a look. NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXmSlMAAoJEDnsnt1WYoG5PcIP/Av4d4LSFVDzocrYrTluQLvp UynpvW3WQzeIyabbX6XfaBE4nwUm+vec/4Tj3voFcn6TrldBMeRkfT+rdV+fktnU 71IX8tuutfcD4fkFkbz/tOYuMQX6oSfZl2YBIGfdfx/CYzqCICYbXoq4HphdPZ1R e2ry/q7Jg/x3uq4rswpLuCGV6ivboACiE4TcS2rirHl5IaIVFx7I/U7cpTAISeKq BmysAdvFKMvcDMqMBj+GD3g4PL4dOFjHhrhG0uF454K5fRNyZ4H3tIQu0/6iwkhK NTMxtPvkr5qgjvxh6JHv60HOEZaOtOZy+Tcnaq4PUi2Ui8tSa8YQy9/AP1CqbuEs hIn5LLdRzsg4Jzue9e/FbIJtsARXJCP86ItqE0MBi+LISi+TbFKEWpBnVh8C5H5V gYyAvudBfKSPncoiUslC0BcOFpydCRS40nBH2ozvBCAribdjnWfh/nTVaV9AgPuX AFaBVvYr/cXbdsXpreCHpePT3bfNkfJJTik45amUFR2tUTKkKueEpjOZlbhxyeTA 0CvrmdJ6taNj7AUfUUrUlUuS7Czw3zMwSIG7NaiqDP9yYB0HtR/lL2333iNehVkV SWmACtVEmN0vuPbCdwefeLiW8+R0k1ucBFgslwutrPFA9t3KmOWY0o2heM9gpWRu rtQ5CPohPmKiahWfnnpz =DogW -----END PGP SIGNATURE----- --=-=-=--