From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1576AC4332F for ; Tue, 22 Nov 2022 02:43:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7544B6B0071; Mon, 21 Nov 2022 21:43:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 703F56B0073; Mon, 21 Nov 2022 21:43:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CB8A6B0074; Mon, 21 Nov 2022 21:43:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4ACAA6B0071 for ; Mon, 21 Nov 2022 21:43:39 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 23D94140510 for ; Tue, 22 Nov 2022 02:43:39 +0000 (UTC) X-FDA: 80159532558.27.8125C23 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf04.hostedemail.com (Postfix) with ESMTP id AB2B940003 for ; Tue, 22 Nov 2022 02:43:38 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id w3-20020a17090a460300b00218524e8877so284478pjg.1 for ; Mon, 21 Nov 2022 18:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=a5nZio34a7iO8a+Fk6WwE3Rm4GJSqkWAtcImuxPFRVI=; b=T7kae4evFTD4VQsvLzIk4/oUaJ/dj+a6RCKO2C2LZNjWdvLR7CbKHt5pG/SwrfY/rt Jqm1mkH/zFV+EWLDhfQcxtYbhXY2Onme/FyKmDFVj6g2AgFpcNwGPFX0Vyhxvhba3cqQ PsYa7aIcnfTvwBvj4Qeot+BHNPh/M6AMGIj6k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=a5nZio34a7iO8a+Fk6WwE3Rm4GJSqkWAtcImuxPFRVI=; b=X3xuNeF/21XdDw8hZb9m4Aw+IaFEWIMH5BhkIMCw4qRJUnWI3d5KRVwkE5PcEejVu5 VzqinwDGmBE4Oy7Zqi8vNsBaz3B7mOsxQSQznztCFzz9h38ljQan2H2rmydLz75Y9tan 6DyVcZAzW0ZQXWnmP/DwjE4P3sMbTuMQ2JN1ihpyrj5O0IdePCxmGYaTMIk3qa1wkrHP fI2h5hKWbNvKKMVr45ZFGAXVkd9TgRUH1AoyZrgkv2eW+S09nyaPDBZ9XgbcNgdAYEr0 U0LEOCJ0U9DKuBU0KmNEM9uPMuBQvEtYkiDDYAc6H7cSZ8IoGhyPzJel2kn+UJVTfITM p0IA== X-Gm-Message-State: ANoB5pkbhWM++msUmJ1ET0OUFA+nXf/VYS8BHwiM4KMNW62r0GlCPERd InF8GyfjAqgpz8+U2cRlhFetrRAf4g/gzQ== X-Google-Smtp-Source: AA0mqf7asHdpOm0LjzuKd/lWwQdaHLMxAw5CQhjDkTT7/3lG4NHEQ9uROlM11vvl7godqRgRzsWqLw== X-Received: by 2002:a17:902:7042:b0:186:7fce:5ec9 with SMTP id h2-20020a170902704200b001867fce5ec9mr5765496plt.48.1669085017594; Mon, 21 Nov 2022 18:43:37 -0800 (PST) Received: from google.com ([240f:75:7537:3187:e258:71ac:37b7:2d52]) by smtp.gmail.com with ESMTPSA id v4-20020a1709029a0400b001782398648dsm10532350plp.8.2022.11.21.18.43.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 18:43:36 -0800 (PST) Date: Tue, 22 Nov 2022 11:43:32 +0900 From: Sergey Senozhatsky To: Andrew Morton Cc: Sergey Senozhatsky , Seth Jennings , Dan Streetman , Vitaly Wool , Nhat Pham , Johannes Weiner , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] zswap: do not allocate from atomic pool Message-ID: References: <20221122013338.3696079-1-senozhatsky@chromium.org> <20221121175619.f38259bac177de86bd9eb558@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221121175619.f38259bac177de86bd9eb558@linux-foundation.org> ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=T7kae4ev; spf=pass (imf04.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.51 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669085018; a=rsa-sha256; cv=none; b=pqp2nUhORA7l1GgdB6F2dZrGk9Zemnwv6XVjsA8gw9RGIQWOwmJeGxA2Ys3nQtSeexj4rn 4aq8pH1w/Wg55tZQm9qJiVSAKCn5nNMyDeTA7AMhwVUbYVapV5QTHn0OvI/RnoB/N8s0AR pcI9b4h14yej2Jfj6nA9/mISj2IprQQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669085018; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=a5nZio34a7iO8a+Fk6WwE3Rm4GJSqkWAtcImuxPFRVI=; b=UT1C8bllT5FYwdr4/cpA3FNyEJRjfwcxnIxuS047pHK9AbA1pQGJ27mGyJzTOtYJwt6S74 Rwrre3j8ninC4BVPtQWUL2duuy7PSNVOhbdlw1kGx5uXzNWi46KdseKmOX3bxadKWZtSVx m1O5sjIDxXLQxSmie8gvA1eEraaUco8= X-Stat-Signature: ey4ik5qh1edqkd885q4u7a58bz7n4wdy X-Rspamd-Server: rspam08 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=T7kae4ev; spf=pass (imf04.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.51 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Queue-Id: AB2B940003 X-HE-Tag: 1669085018-447651 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On (22/11/21 17:56), Andrew Morton wrote: > > zswap_frontswap_load() should be called from preemptible > > context (we even call mutex_lock() there) and it does not > > look like we need to do GFP_ATOMIC allocaion for temp > > buffer there. Use GFP_KERNEL instead. > > > > ... > > > > --- a/mm/zswap.c > > +++ b/mm/zswap.c > > @@ -1314,7 +1314,7 @@ static int zswap_frontswap_load(unsigned type, pgoff_t offset, > > } > > > > if (!zpool_can_sleep_mapped(entry->pool->zpool)) { > > - tmp = kmalloc(entry->length, GFP_ATOMIC); > > + tmp = kmalloc(entry->length, GFP_KERNEL); > > if (!tmp) { > > ret = -ENOMEM; > > goto freeentry; > > It seems strange to do It does indeed. > if (! can sleep) > do something which can sleep Some allocators enter the non-preemptible context in ->map callback and exit that context in ->unmap. zswap uses async compression and needs to wait for crypto to finish decompression of the mapped object, which it cannot do when allocator disables preemption in ->map. So for allocators that do this zswap allocates a temp buffer, then maps the object, copies it to that temp buffer and unmaps the objects. So now it can wait for async crypto because we are in preemptible context and we use the temp copy of the object. > or am I misreading the intent of zpool_driver.sleep_mapped? If so, > perhaps some explanatory code comments will help. I can add one. I assume at mm/zpool.c zpool_can_sleep_mapped() would be the right place.