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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 DE63CC433DB for ; Tue, 22 Dec 2020 09:32:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 65D9F2310D for ; Tue, 22 Dec 2020 09:32:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 65D9F2310D 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 8EA926B009D; Tue, 22 Dec 2020 04:32:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 89B456B00A0; Tue, 22 Dec 2020 04:32:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7624E8D0003; Tue, 22 Dec 2020 04:32:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id 5FE206B009D for ; Tue, 22 Dec 2020 04:32:10 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2D9FC8249980 for ; Tue, 22 Dec 2020 09:32:10 +0000 (UTC) X-FDA: 77620402020.08.act81_4c009062745e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 150531819E624 for ; Tue, 22 Dec 2020 09:32:10 +0000 (UTC) X-HE-Tag: act81_4c009062745e X-Filterd-Recvd-Size: 7161 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Dec 2020 09:32:09 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id b26so20907083lff.9 for ; Tue, 22 Dec 2020 01:32:09 -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=SofsUU21+w366eNXquGkYbE99uew3PDdcRX7eYlFPoo=; b=aYms1QcCE+GnnBkWPvY0/w2ktmXny7n24bSgO0t2fqjTYr6OC04UrjP9nOLkw/n8uD LBEyVH0K3YeXnTMAAPEtcsZU37B2yl8qcq5Vk2z3Zi9O6ibqXyf28VE5eOt4SF52j3KS WycewPxhGXm8S999w6yUuodRRO5xA4QXWUkRc= 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=SofsUU21+w366eNXquGkYbE99uew3PDdcRX7eYlFPoo=; b=E+UMOrqfirn4/kul/u4XB8Kc54x2BPV9uhg451nqwZKihxKBzklcrjN7NZY8C+pSv/ fFSgVnnufkmik1pLb3qnVSyd707BqmmJ8dSLT46poIQdlb/GvPvZBnVscYLL1WmFKIxD CK/wQ02YFHMirYhTYwpPUFGwEll9k3BfnY1ztfq3xmGnE9FdYjd8hTAvS6EqN+x7XmH/ RYfGp8kOHW7/z7lajrh5uj3GGSfdrnR8TUfLQwWdSTKEmn4eJp4MxvqOqzRThb89aBFT LoBzTxejaSi9q3td/OI/PMpSMwiCuVMOUtG1O8POgX0aB8y2WCw74W5IRx5lrjFsB4xq I28w== X-Gm-Message-State: AOAM533cXOJQ0O4q4V+xfyFsp7/baDHnagagbEW0zgaLVGo+BmndOZNK MsgOuEV6OB4aIv1qBrwWreQ8oEUYUMlhOPczQxG4rw== X-Google-Smtp-Source: ABdhPJwJI7cIZIoSi2ir9NNMLzcpQ9MHFjW+1aDbOdgUw6AFWjJMFM1E6xA40NjpgxssoZNTY5kVbLRV8nsbuzfPTso= X-Received: by 2002:ac2:5edb:: with SMTP id d27mr8046314lfq.411.1608629528032; Tue, 22 Dec 2020 01:32:08 -0800 (PST) MIME-Version: 1.0 References: <18669bd607ae9efbf4e00e36532c7aa167d0fa12.camel@gmx.de> <20201220002228.38697-1-vitaly.wool@konsulko.com> <8cc0e01fd03245a4994f2e0f54b264fa@hisilicon.com> <8f17abe06057498dba9413f706b86207@hisilicon.com> <0777a34e3e9246fe83e693ba07405d28@AcuMS.aculab.com> In-Reply-To: <0777a34e3e9246fe83e693ba07405d28@AcuMS.aculab.com> From: Vitaly Wool Date: Tue, 22 Dec 2020 10:32:02 +0100 Message-ID: Subject: Re: [PATCH] zsmalloc: do not use bit_spin_lock To: David Laight Cc: "Song Bao Hua (Barry Song)" , Shakeel Butt , Minchan Kim , Mike Galbraith , LKML , linux-mm , Sebastian Andrzej Siewior , NitinGupta , Sergey Senozhatsky , Andrew Morton Content-Type: multipart/alternative; boundary="000000000000980bf105b70a3f82" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --000000000000980bf105b70a3f82 Content-Type: text/plain; charset="UTF-8" On Tue, 22 Dec 2020, 10:20 David Laight, wrote: > From: Song Bao Hua > > Sent: 21 December 2020 23:02 > ... > > > For decompression, I would like as low latency as possible which I > > > think is only possible by doing decompression on a cpu synchronously. > > > > One possibility is that we change HW accelerator driver to be sync > > polling for decompression. But this still depends on async api as > > this is the framework nowadays, the difference would be the driver > > won't really block. crypto_wait_req() will return without actual > > sleep. > > How long does the HW accelerated compress/decompress need to be before > it is actually worth sleeping the process? > While the HW version might be faster than the SW one, it may not be > enough faster to allow for the hardware interrupt and process sleep. > So it may be worth just spinning (polling the hardware register) > until the request completes. > > If decompress are done that way, but compress left async, then > the decompress might need to fallback to SW if the HW is busy. > This is an option too, of course. However please bear in mind that Kerne mutexes are hybrid in the sense that there will be normally some spinning first. ~Vitaly > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 > 1PT, UK > Registration No: 1397386 (Wales) > --000000000000980bf105b70a3f82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 22 Dec 2020, 10:20 David Laight, <David.Laight@aculab.com> wrote:<= br>
From: Song Bao Hua
> Sent: 21 December 2020 23:02
...
> > For decompression, I would like as low latency as possible which = I
> > think is only possible by doing decompression on a cpu synchronou= sly.
>
> One possibility is that we change HW accelerator driver to be sync
> polling for decompression. But this still depends on async api as
> this is the framework nowadays, the difference would be the driver
> won't really block. crypto_wait_req() will return without actual > sleep.

How long does the HW accelerated compress/decompress need to be before
it is actually worth sleeping the process?
While the HW version might be faster than the SW one, it may not be
enough faster to allow for the hardware interrupt and process sleep.
So it may be worth just spinning (polling the hardware register)
until the request completes.

If decompress are done that way, but compress left async, then
the decompress might need to fallback to SW if the HW is busy.

This is an op= tion too, of course. However please bear in mind that Kerne mutexes are hyb= rid in the sense that there will be normally some spinning first.=C2=A0

~Vitaly=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A0 David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK
Registration No: 1397386 (Wales)
--000000000000980bf105b70a3f82--