mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: <Conor.Dooley@microchip.com>
To: <jszhang@kernel.org>, <Conor.Dooley@microchip.com>
Cc: <paul.walmsley@sifive.com>, <palmer@dabbelt.com>,
	<aou@eecs.berkeley.edu>, <linux-riscv@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <ajones@ventanamicro.com>
Subject: Re: [PATCH v2] riscv: enable THP_SWAP for RV64
Date: Tue, 30 Aug 2022 14:15:45 +0000	[thread overview]
Message-ID: <d9331af0-58bc-ed3b-10f5-8509795e3198@microchip.com> (raw)
In-Reply-To: <Yw4XwsVQBB1HRw04@xhacker>

On 30/08/2022 14:59, Jisheng Zhang wrote:
> On Mon, Aug 29, 2022 at 05:27:48PM +0000, Conor.Dooley@microchip.com wrote:
>> On 29/08/2022 15:10, Jisheng Zhang wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> On Sat, Aug 27, 2022 at 09:13:03PM +0000, Conor.Dooley@microchip.com wrote:
>>>> Hey Jisheng,
>>>
>>> Hi Conor,
>>>
>>>> On 27/08/2022 10:58, Jisheng Zhang wrote:
>>>>> I have a Sipeed Lichee RV dock board which only has 512MB DDR, so
>>>>> memory optimizations such as swap on zram are helpful. As is seen
>>>>> in commit d0637c505f8a ("arm64: enable THP_SWAP for arm64") and
>>>>> commit bd4c82c22c367e ("mm, THP, swap: delay splitting THP after
>>>>> swapped out"), THP_SWAP can improve the swap throughput significantly.
>>>>>
>>>>> Enable THP_SWAP for RV64, testing the micro-benchmark which is
>>>>> introduced by commit d0637c505f8a ("arm64: enable THP_SWAP for arm64")
>>>>> shows below numbers on the Lichee RV dock board:
>>>>>
>>>>> thp swp throughput w/o patch: 66908 bytes/ms (mean of 10 tests)
>>>>> thp swp throughput w/ patch: 322638 bytes/ms (mean of 10 tests)
>>>>
>>>> I know the original commit message contains this, but it's a little
>>>> odd. If the patch /enables/ THP then how would there be THP swap
>>>> prior to the patch?
>>>
>>> hmm, it's swap I'll send a v3 to correct the description.
>>>
>>>>
>>>>>
>>>>> Improved by 382%!
>>>>
>>>> I could not replicate the after numbers on my nezha, so I suspect
>>>> I am missing something in my config/setup. zswap is enabled and is
>>>
>>> swap on zram rather than zswap ;)
>>
>> I think I tried about 30 different config variations, initially not
>> using zswap and later using it.
>> My zramctl looks like so (although I did try zstd too) after running
>> the demo application from that commit:
>>
>> NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
>> /dev/zram0 lzo-rle       241M  22M  8.4M  9.1M       1 [SWAP]
>>
>> I am using the default riscv defconfig + the following:
>> CONFIG_ZRAM=y
>> CONFIG_CRYPTO_DEFLATE=y
>> CONFIG_CRYPTO_LZO=y
>> CONFIG_CRYPTO_ZSTD=y
>> CONFIG_ZRAM_MEMORY_TRACKING=y
>> CONFIG_TRANSPARENT_HUGEPAGE=y
>> CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
>> CONFIG_THP_SWAP=y
>>
>> Am I just missing something obvious here?
> 
> similar config options here. what's your rootfs? Is your board busy
> with something? I used a minimal rootfs built from buildroot.
> can you plz show your numbers w/ and w/o the patch?

I was using fedora for the testing, downloaded directly from
koji. My before/after numbers varied, but were around 80,000
bytes/ms most of the time.

If I increased the size to 500 * 1024 * 1024 I got around 130k.

Before/after the patch, the numbers did not really change, but
things did fluctuate quite wildly - from about 50k to 90k using
the 400 size.

> 
> I also tried the simple benchmark on qemu(just for reference, since
> I have no other riscv boards except the lichee RV dock board):
> swp out w/o patch: 30066 bytes/ms (mean of 10 tests)
> swp out w/ patch: 130055 bytes/ms (mean of 10 tests)
> so improved by 332.7% 

I'll give QEMU a go so :)

  reply	other threads:[~2022-08-30 14:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-27  9:58 Jisheng Zhang
2022-08-27 21:13 ` Conor.Dooley
2022-08-29 14:10   ` Jisheng Zhang
2022-08-29 17:27     ` Conor.Dooley
2022-08-30 13:59       ` Jisheng Zhang
2022-08-30 14:15         ` Conor.Dooley [this message]
2022-08-30 14:26           ` Conor.Dooley
2022-08-30 14:31             ` Jisheng Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d9331af0-58bc-ed3b-10f5-8509795e3198@microchip.com \
    --to=conor.dooley@microchip.com \
    --cc=ajones@ventanamicro.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=jszhang@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®