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 X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A569C433E0 for ; Wed, 23 Dec 2020 00:11:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C9ECF22573 for ; Wed, 23 Dec 2020 00:11:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9ECF22573 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 295F96B0099; Tue, 22 Dec 2020 19:11:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2478B6B009B; Tue, 22 Dec 2020 19:11:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 112638D0001; Tue, 22 Dec 2020 19:11:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0197.hostedemail.com [216.40.44.197]) by kanga.kvack.org (Postfix) with ESMTP id EAEC56B0099 for ; Tue, 22 Dec 2020 19:11:30 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BB062181AEF3C for ; Wed, 23 Dec 2020 00:11:30 +0000 (UTC) X-FDA: 77622617940.10.judge75_5c14e7d27464 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 9D5FF16A4A4 for ; Wed, 23 Dec 2020 00:11:30 +0000 (UTC) X-HE-Tag: judge75_5c14e7d27464 X-Filterd-Recvd-Size: 7315 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Dec 2020 00:11:29 +0000 (UTC) Received: by mail-lf1-f41.google.com with SMTP id o13so36070050lfr.3 for ; Tue, 22 Dec 2020 16:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2LLo3hmxVXUaUgVEfTkvoDCRls0Ztd6U6q/1VD4QX9g=; b=klH8+HLOGzBPUwTCJxWtqi0h2C/4vhia6SFlwZb32VLCd0FmLHrEetndB2ePjTWskm 9frB7Qb75WoEHvCxmu3f+Z8gjQC62EhURROPKK4QRh3rxXf2+qWwy5RdX05ipE57wKKK KAywsx1V8exG1Hl11YbqLKErPDImpLXr8BqWs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2LLo3hmxVXUaUgVEfTkvoDCRls0Ztd6U6q/1VD4QX9g=; b=JHklh2HDRLJwlFXAkQa98Ub2CTbYSigtwSlxHYWjoy4X3M8tQ0f2lLreR9Pc9Fz630 Y5pE6T6cP9CHMBNZWzvomPIM/XeGiFqQ7z3lrHOwL6U6mn1FkAO+CJ52rRlAjeT21R9a myC+jfodEFvtOxBSBPQFCLpBknLjfqznnxyIt1hVVlLNlN0ImM1dxHBbh1aJ1H4W9kQF kMPZFffF0Izh1/sKqzpW0R8Eerdyt3/ZbqJcjuB6sQD6Idl8Y2sYsPUOGD15p3La5HJV jCMaZKwawAqIXbWsBL895+ccUG5mE+AaNN4Yp/mokWzamVPbZqpD0CHinyzzXxn4AC9S GxUw== X-Gm-Message-State: AOAM53034QquQKGS0uzNx7+bW2UeLNl7Y1GYwJisB6yrTmI9FPIqXXE7 GQlu7SzsrJwoLV9vRMr/79BJnmdcbAeMeRx6iUh/pA== X-Google-Smtp-Source: ABdhPJyxT+xMisXBx5G2vhMJlTM2OBO9kGepIFvEhZ7mIgqIzu6UdC0onCmYPOLwlEb9rQ6UhZmrX7Z2oSo4DTWrr8c= X-Received: by 2002:a2e:b8c4:: with SMTP id s4mr8285957ljp.269.1608682288581; Tue, 22 Dec 2020 16:11:28 -0800 (PST) MIME-Version: 1.0 References: <18669bd607ae9efbf4e00e36532c7aa167d0fa12.camel@gmx.de> <20201220002228.38697-1-vitaly.wool@konsulko.com> <8cc0e01fd03245a4994f2e0f54b264fa@hisilicon.com> <4490cb6a7e2243fba374e40652979e46@hisilicon.com> <08cbef1e43634c4099709be8e99e5d27@hisilicon.com> <1d0d4a3576e74d128d7849342a7e9faf@hisilicon.com> In-Reply-To: <1d0d4a3576e74d128d7849342a7e9faf@hisilicon.com> From: Vitaly Wool Date: Wed, 23 Dec 2020 01:11:17 +0100 Message-ID: Subject: Re: [PATCH] zsmalloc: do not use bit_spin_lock To: "Song Bao Hua (Barry Song)" Cc: Shakeel Butt , Minchan Kim , Mike Galbraith , LKML , linux-mm , Sebastian Andrzej Siewior , NitinGupta , Sergey Senozhatsky , Andrew Morton , "tiantao (H)" Content-Type: text/plain; charset="UTF-8" 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 Tue, 22 Dec 2020, 22:06 Song Bao Hua (Barry Song), wrote: > > > > > -----Original Message----- > > From: Vitaly Wool [mailto:vitaly.wool@konsulko.com] > > Sent: Tuesday, December 22, 2020 10:44 PM > > To: Song Bao Hua (Barry Song) > > Cc: Shakeel Butt ; Minchan Kim ; Mike > > Galbraith ; LKML ; linux-mm > > ; Sebastian Andrzej Siewior ; > > NitinGupta ; Sergey Senozhatsky > > ; Andrew Morton > > ; tiantao (H) > > Subject: Re: [PATCH] zsmalloc: do not use bit_spin_lock > > > > On Tue, 22 Dec 2020, 03:11 Song Bao Hua (Barry Song), > > wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Song Bao Hua (Barry Song) > > > > Sent: Tuesday, December 22, 2020 3:03 PM > > > > To: 'Vitaly Wool' > > > > Cc: Shakeel Butt ; Minchan Kim ; > > Mike > > > > Galbraith ; LKML ; linux-mm > > > > ; Sebastian Andrzej Siewior ; > > > > NitinGupta ; Sergey Senozhatsky > > > > ; Andrew Morton > > > > ; tiantao (H) > > > > Subject: RE: [PATCH] zsmalloc: do not use bit_spin_lock > > > > > > > > > > > > > I'm still not convinced. Will kmap what, src? At this point src might > > become > > > > just a bogus pointer. > > > > > > > > As long as the memory is still there, we can kmap it by its page struct. > > But > > > > if > > > > it is not there anymore, we have no way. > > > > > > > > > Why couldn't the object have been moved somewhere else (due to the compaction > > > > mechanism for instance) > > > > > at the time DMA kicks in? > > > > > > > > So zs_map_object() will guarantee the src won't be moved by holding those > > > > preemption-disabled lock? > > > > If so, it seems we have to drop the MOVABLE gfp in zswap for zsmalloc case? > > > > > > > > > > Or we can do get_page() to avoid the movement of the page. > > > > > > I would like to discuss this more in zswap context than zsmalloc's. > > Since zsmalloc does not implement reclaim callback, using it in zswap > > is a corner case anyway. > > I see. But it seems we still need a solution for the compatibility > of zsmalloc and zswap? this will require change in either zsmalloc > or zswap. > or do you want to make zswap depend on !ZSMALLOC? No, I really don't think we should go that far. What if we add a flag to zpool, named like "can_sleep_mapped", and have it set for zbud/z3fold? Then zswap could go the current path if the flag is set; and if it's not set, and mutex_trylock fails, copy data from src to a temporary buffer, then unmap the handle, take the mutex, process the buffer instead of src. Not the nicest thing to do but at least it won't break anything. ~Vitaly > > zswap, on the other hand, may be dealing with some new backends in > > future which have more chances to become mainstream. Imagine typical > > NUMA-like cases, i. e. a zswap pool allocated in some kind SRAM, or in > > unused video memory. In such a case if you try to use a pointer to an > > invalidated zpool mapping, you are on the way to thrash the system. > > So: no assumptions that the zswap pool is in regular linear RAM should > > be made. > > > > ~Vitaly > > Thanks > Barry