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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham 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 5C5D3C4361B for ; Sun, 20 Dec 2020 21:20:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7EAAB229C4 for ; Sun, 20 Dec 2020 21:20:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EAAB229C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hisilicon.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E11656B005C; Sun, 20 Dec 2020 16:20:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DC2A86B005D; Sun, 20 Dec 2020 16:20:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD8B16B0068; Sun, 20 Dec 2020 16:20:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id B4D6F6B005C for ; Sun, 20 Dec 2020 16:20:43 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7769C3640 for ; Sun, 20 Dec 2020 21:20:43 +0000 (UTC) X-FDA: 77614929966.24.van36_2a181d227451 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 543551A4A7 for ; Sun, 20 Dec 2020 21:20:43 +0000 (UTC) X-HE-Tag: van36_2a181d227451 X-Filterd-Recvd-Size: 5124 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Sun, 20 Dec 2020 21:20:41 +0000 (UTC) Received: from DGGEMM406-HUB.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Czb8c4J4kz53dn; Mon, 21 Dec 2020 05:19:44 +0800 (CST) Received: from dggemi761-chm.china.huawei.com (10.1.198.147) by DGGEMM406-HUB.china.huawei.com (10.3.20.214) with Microsoft SMTP Server (TLS) id 14.3.498.0; Mon, 21 Dec 2020 05:20:36 +0800 Received: from dggemi761-chm.china.huawei.com (10.1.198.147) by dggemi761-chm.china.huawei.com (10.1.198.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Mon, 21 Dec 2020 05:20:36 +0800 Received: from dggemi761-chm.china.huawei.com ([10.9.49.202]) by dggemi761-chm.china.huawei.com ([10.9.49.202]) with mapi id 15.01.2106.002; Mon, 21 Dec 2020 05:20:36 +0800 From: "Song Bao Hua (Barry Song)" To: Mike Galbraith , Vitaly Wool , LKML , linux-mm CC: Sebastian Andrzej Siewior , Minchan Kim , NitinGupta Subject: RE: [PATCH] zsmalloc: do not use bit_spin_lock Thread-Topic: [PATCH] zsmalloc: do not use bit_spin_lock Thread-Index: AQHW1mZAeBjE5clI7UKUuMSOCQsyuqn+qqCAgABrOwCAAWYo8A== Date: Sun, 20 Dec 2020 21:20:36 +0000 Message-ID: <44a69faf3ac54b5883a4b0d99d51a0b0@hisilicon.com> References: <18669bd607ae9efbf4e00e36532c7aa167d0fa12.camel@gmx.de> <20201220002228.38697-1-vitaly.wool@konsulko.com> <80d3be3d47356bf0bd6c5a9d9dc658ca3da292be.camel@gmx.de> In-Reply-To: <80d3be3d47356bf0bd6c5a9d9dc658ca3da292be.camel@gmx.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.201.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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: > -----Original Message----- > From: Mike Galbraith [mailto:efault@gmx.de] > Sent: Sunday, December 20, 2020 8:48 PM > To: Vitaly Wool ; LKML > ; linux-mm > Cc: Song Bao Hua (Barry Song) ; Sebastian And= rzej > Siewior ; Minchan Kim ; NitinG= upta > > Subject: Re: [PATCH] zsmalloc: do not use bit_spin_lock >=20 > On Sun, 2020-12-20 at 02:23 +0100, Mike Galbraith wrote: > > On Sun, 2020-12-20 at 02:22 +0200, Vitaly Wool wrote: > > > zsmalloc takes bit spinlock in its _map() callback and releases it > > > only in unmap() which is unsafe and leads to zswap complaining > > > about scheduling in atomic context. > > > > > > To fix that and to improve RT properties of zsmalloc, remove that > > > bit spinlock completely and use a bit flag instead. > > > > It also does get_cpu_var() in map(), put_cpu_var() in unmap(). >=20 > That aside, the bit spinlock removal seems to hold up to beating in RT. > I stripped out the RT changes to replace the bit spinlocks, applied the > still needed atm might_sleep() fix, and ltp zram and zswap test are > running in a loop with no signs that it's a bad idea, so I hope that > makes it in (minus the preempt disabled spin which I whacked), as it > makes zsmalloc markedly more RT friendly. >=20 > RT changes go from: > 1 file changed, 79 insertions(+), 6 deletions(-) > to: > 1 file changed, 8 insertions(+), 3 deletions(-) >=20 Sorry, would you like to show the change for=20 "8 insertions(+), 3 deletions(-)"? BTW, your original patch looks not right as=20 crypto_wait_req(crypto_acomp_decompress()...) can sleep too. [copy from your original patch with comment] --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1258,20 +1258,20 @@ static int zswap_frontswap_load(unsigned /* decompress */ dlen =3D PAGE_SIZE; + acomp_ctx =3D raw_cpu_ptr(entry->pool->acomp_ctx); + mutex_lock(acomp_ctx->mutex); src =3D zpool_map_handle(entry->pool->zpool, entry->handle, ZPOOL_MM_RO); if (zpool_evictable(entry->pool->zpool)) src +=3D sizeof(struct zswap_header); - acomp_ctx =3D raw_cpu_ptr(entry->pool->acomp_ctx); - mutex_lock(acomp_ctx->mutex); sg_init_one(&input, src, entry->length); sg_init_table(&output, 1); sg_set_page(&output, page, PAGE_SIZE, 0); acomp_request_set_params(acomp_ctx->req, &input, &output, entry->length, = dlen); /*!!!!!!!!!!!!!!!! * here crypto could sleep !!!!!!!!!!!!!!*/ ret =3D crypto_wait_req(crypto_acomp_decompress(acomp_ctx->req), &acomp_c= tx->wait); - mutex_unlock(acomp_ctx->mutex); zpool_unmap_handle(entry->pool->zpool, entry->handle); + mutex_unlock(acomp_ctx->mutex); BUG_ON(ret); freeentry: [end] so I guess we have to fix zsmalloc. > -Mike Thanks Barry