From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756128AbcFHN7L (ORCPT ); Wed, 8 Jun 2016 09:59:11 -0400 Received: from mail-db5eur01on0107.outbound.protection.outlook.com ([104.47.2.107]:40000 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755946AbcFHN7J (ORCPT ); Wed, 8 Jun 2016 09:59:09 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=VDavydov@virtuozzo.com; Date: Wed, 8 Jun 2016 16:59:00 +0300 From: Vladimir Davydov To: Michal Hocko CC: , , Andrew Morton , LKML , Michal Hocko Subject: Re: [RFC PATCH] mm, memcg: use consistent gfp flags during readahead Message-ID: <20160608135900.GB30465@esperanza> References: <1465301556-26431-1-git-send-email-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1465301556-26431-1-git-send-email-mhocko@kernel.org> X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: DB5PR10CA0029.EURPRD10.PROD.OUTLOOK.COM (2a01:111:e400:5a82::39) To AM3PR08MB0579.eurprd08.prod.outlook.com (2a01:111:e400:c408::13) X-MS-Office365-Filtering-Correlation-Id: 5765866f-b0be-4995-93df-08d38fa50dc1 X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0579;2:c/pmosvbMAH0PAfDGoD+SmHlnK6BeOQyl2rhzJWEaiMwHlWogPhMN+FR1bvVq37qUV4xn6CH/xoCPRnFySGY8iQEpyO6ZUVTX+pIDT4gTgPKxNZ7A+9zJY5KBymlN4h7K46+gGp66FS0YHFNS3AD1qzS7op/Fsz++o/xsvbVY1v+uKD/8KqiTQdb8sxI3aJy;3:r19DkAV8PSuIrAxDjAgqNW2w36ZcLY7scMY40zWGVh4wgGKGJvjXnFRAnFY0vhOxYnv+DAfKDLBChmbEdVPY3WfmlHw1sZ1h5SY0ZR7PxNsqf8MiSRNkBIt6Fr+DenID X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR08MB0579; X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0579;25:gv4aA9+fd+rk7boimquYLrIFyYz+C3A9yWPKKh9687ZzKf0TvrqJVSwhwhtFBb8wBtWMEyZCWSB6cBIizg9C/If6HDXaPtENJ4nNV/1Ku0n6y3FYT8B6lMRyfYDf9ts8YFGyoRzwcDZXiY6A+qzTOu+rq4w1eFwkT2+2MbiCwqIkyaZ2VKQf4PmdPhcDaKtwtEDkhTJidX4RuTEELgmHUo3BxxxQrj83R5oBxXVVEGJtIydNeP3lj6S8GXT4We8P1dNi8DYF40Jmfve60knfeCoqucXXkpwi/Lp2lceWTiTVqnSLubyL8V7G5U/O4U16InUSP+M7dabG151fZrRV7JXcA+GUSgwqsxmaqzry7UEIxhqyWDBw6bgrGlGTibRJebumBFkU8Tp2lJt+2Zs6haqKmoTEZm+a/GqwP/S1C0WaLdx8ea30XDck2Rr5kgLOHFjIOz51qgt2KmxjD1TR8kBmiqdpP/94F24NMc/mF8b6anJtcVvgfRUG4DByxuE986EN8fnszQM++pQkRhjhrXHvYQ83Bk5G3OA/RtCCcWkD7WBFH+fhugurnmqtz3vktwWRwddODLHsko5HloYWz7ysOiNERyZwgDNAQQTci+dxSETRGVa51AbvCSKqkD3AG+5fCFPv52BtXQlAodshb7/fv8ntztMP+W69KY8pmli3m20Q6gyV6SYiOpRyzLs5U5srBBUOeKcD8cEFrXICZA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046);SRVR:AM3PR08MB0579;BCL:0;PCL:0;RULEID:;SRVR:AM3PR08MB0579; X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0579;4:9qrWcwwj7luIF6Vq3xNCx1Dy/+pZL5jBplKY+NY7I+aVvIZsfffsCxrqzuhdyojEmnUj9H34qNkkJTYGN08exYVe8qtTe05EWUYL8dcIorjmEVL6zu6m3qzrAHsdNX49seSICsjeUk24KAbTmrdPFnYsmcImhqbzEhn7Ws4Fr+Pd+lmE4lISDu/B297Jcr46LmoL7EruPS201Ur0qQloFiKNpKUCvjIvpbzEKqKQP+0j7VtXG/l6iDiqHEgEOcNB79/VfMUnLyPLDfLmU0sxc01C5D7WiGi74AwV1/2C/i+vllsOMWXhMn955KsDn7HAWBy+hSuvUU0BsWbMj0+YDu+TokOtFXY7FsFcAAAIZS6+CKJ5k49ssEDd3sSjprCdwAU8+1IuLBPQAXmYqm+AcVPTQF21sbIocU0abmcnSRY= X-Forefront-PRVS: 0967749BC1 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(52314003)(199003)(189002)(24454002)(54094003)(68736007)(19580395003)(33656002)(5008740100001)(80792005)(5004730100002)(8676002)(101416001)(9686002)(76176999)(2906002)(19580405001)(50986999)(54356999)(4326007)(23726003)(33716001)(1076002)(6116002)(586003)(66066001)(97756001)(47776003)(46406003)(92566002)(97736004)(105586002)(81156014)(86362001)(42186005)(106356001)(3846002)(110136002)(189998001)(50466002)(81166006)(2950100001);DIR:OUT;SFP:1102;SCL:1;SRVR:AM3PR08MB0579;H:esperanza;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;AM3PR08MB0579;23:Q01P7Z7saXDLXi28TgTuhLABCKYam2HgBB140zfrB?= =?us-ascii?Q?PAm7oC3TVN0wBMXBDftCmj6KkB+SFX0XrGe9fzqw6621uHomkIme9aQ9h37F?= =?us-ascii?Q?sdN5z+wx2us1GoaIcU/f7xtDF5Eyxn/8DwppDht6alDCl1AAZ5QFpQMBj3G3?= =?us-ascii?Q?R2yEDhexe4EqT/pYCrNI4mCv9yU3bhpcqpjH1Rar7BKIy9Z/2oj4u1BdAhJi?= =?us-ascii?Q?tgSFFKHLRHNI8sY/UlROtn9mrUPhx/DNKxxYz6AaGug/mLTyDK9X5wl0oyCJ?= =?us-ascii?Q?nLPVU5/v2nCXhxjAMY7+KQzsIfNiLKiP1EDvJtvNpvkUWDquc+Z7HOGsOXm+?= =?us-ascii?Q?WDI5MNp1qW5UrROoqCO3gw3MMs3+7c0UNzPOZ0Pwr/f7Bd58VHyXyVc3IGme?= =?us-ascii?Q?AdakRo2paitT4NcGQFfIw+LEr93mm0QF+rNCH64gjl3ONzYoqoCE6MjF5HSj?= =?us-ascii?Q?7GQ5gPtLs6FdkT6kI3sca2dTKcc0I2txJf9YPaPc8SiTjXN1lZwYNnwm4zK7?= =?us-ascii?Q?T2sb5fsn/WqSLX0CmFvJHXFYN3TgZ3owldHrYuh5SkAIFkAb8ch/0ESky6ec?= =?us-ascii?Q?NVd2rOI8OlSncsMyYzOu/w50iOnv5Vy8XRncDjfpq8/bY3jvNcw4SI0ZdfYo?= =?us-ascii?Q?zOQPftThiNXTSOikxcVWr2GbcR92sOpxQsg5R/EQVHmI9wamt7dQvqFrxVUZ?= =?us-ascii?Q?ekqQbESIRw+DtZpFQbKsCIHCWaUk/EW9AxHv5ImEOLtQoq3loPjVmHv99Bks?= =?us-ascii?Q?a/HKV+vMDgmIiQfV8iBUqaaIc9p1sjxgvDJ+Cs0zrqbmDCUbclb3LOKI1Uii?= =?us-ascii?Q?dkRUU1azvIewYpAFcK5ng+SXzSM8Oz5WFiJchxsee0PKCJYF2tplSn/UwEzd?= =?us-ascii?Q?SzBsPvDkjAyP7zbYHAnB8fgqDigBT6tJob37H4QAw3rq101GhbGuOov1VtJz?= =?us-ascii?Q?RZyWc24aapoEezinpOGmb2TDI0c2WBQINZ2pFqcSIfEDDmjXePBYKD0Sp0gk?= =?us-ascii?Q?Ajm7YObN8QOrnHLDSRKsYqqc2JpPklaFXo74U+cJ7Y4PENwfRhu3OxK7mujH?= =?us-ascii?Q?WHA4FijswiwfptXF0bILXrJ5B6tUyLS6G3REk+7OA8hyw19u+o90U9eiZ/7Y?= =?us-ascii?Q?UOMIi2hY68=3D?= X-Microsoft-Exchange-Diagnostics: 1;AM3PR08MB0579;5:g8l/XnZBrsdbatxzydpvpuDL9HDr8PeYZkR70uhqdza53DnO5/CrFTuyOXzPksuolHvddVRuiZq5x/WrISg/fqfD6m/fROyW6pgigQw64hu6ymizDGXKKJCyruycTNj3vFhP82HNxpcWe2tFr+jTKw==;24:MscDyYmU6CgMfSfHRzNPBCLvjDrpWj8NZHh/p/1jsZUaSnSu7icvHtIEdtdwFzy/kKgy6qHZpkcUFXhilfmd9FHidkQrNQwhtYOEqJ5yDqI=;7:gx8eHe/DBKJQel4Zh06mqn4UMWM+iw/Z05LNMzVWo2i+J6nn18lf2ezBIc8/SltmXIKalWdY36LiGn9lpTopyuM6mUmrI/UljihC8eRxK5W8qvPmp6QTth2tRtKkj0NCy/Bb1pBaK8V9cNatxTv2ES9C8K+w4Sb4s0Hd42chTz4VihTZsLQNs49BwsQBdBRB34b3SyhlsgOD36sTV6hEgZLfX5fsuEyMAwCxkrNNDzo=;20:/B4uFJrNdmOiLtKrKODErlo0zD4uWzlreg3KuUjv3RnabBrd1YwPNfjTTYWvlyS5d2EWtesbDI1p1AnXh8Nr4StUrZBFhmdFFWdSQ94cfwSrr2zkVfm9vWmif138/Il87x2u7S2ksYjy9uhu4xDbZJlqfm13X1BCQHyI2mB0T14= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2016 13:59:04.4725 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR08MB0579 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 07, 2016 at 02:12:36PM +0200, Michal Hocko wrote: > From: Michal Hocko > > Vladimir has noticed that we might declare memcg oom even during > readahead because read_pages only uses GFP_KERNEL (with mapping_gfp > restriction) while __do_page_cache_readahead uses > page_cache_alloc_readahead which adds __GFP_NORETRY to prevent from > OOMs. This gfp mask discrepancy is really unfortunate and easily > fixable. Drop page_cache_alloc_readahead() which only has one user > and outsource the gfp_mask logic into readahead_gfp_mask and propagate > this mask from __do_page_cache_readahead down to read_pages. > > This alone would have only very limited impact as most filesystems > are implementing ->readpages and the common implementation > mpage_readpages does GFP_KERNEL (with mapping_gfp restriction) again. > We can tell it to use readahead_gfp_mask instead as this function is > called only during readahead as well. The same applies to > read_cache_pages. > > ext4 has its own ext4_mpage_readpages but the path which has pages != > NULL can use the same gfp mask. > Btrfs, cifs, f2fs and orangefs are doing a very similar pattern to > mpage_readpages so the same can be applied to them as well. > > Signed-off-by: Michal Hocko > --- > > Hi, > an alternative solution for ->readpages part would be add the gfp mask > as a new argument. This would be a larger change and I am not even sure > it would be so much better. An explicit usage of the readahead gfp mask > sounds like easier to track. If there is a general agreement this is a > proper way to go I can rework the patch to do so, of course. > > Does this make sense? ... > diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c > index dc54a4b60eba..c75b66a64982 100644 > --- a/fs/ext4/readpage.c > +++ b/fs/ext4/readpage.c > @@ -166,7 +166,7 @@ int ext4_mpage_readpages(struct address_space *mapping, > page = list_entry(pages->prev, struct page, lru); > list_del(&page->lru); > if (add_to_page_cache_lru(page, mapping, page->index, > - mapping_gfp_constraint(mapping, GFP_KERNEL))) > + readahead_gfp_mask(mapping))) > goto next_page; > } > ext4 (at least) might issue other allocations in ->readpages, e.g. bio_alloc with GFP_KERNEL. I wonder if it would be better to set GFP_NOFS context on task_struct in read_pages() and handle it in alloc_pages. You've been planning doing something like this anyway, haven't you?