lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 07 May 2021 14:14:24 +0800
From:   "Huang, Ying" <ying.huang@...el.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, yang.shi@...ux.alibaba.com,
        rientjes@...gle.com, dan.j.williams@...el.com, david@...hat.com,
        osalvador@...e.de, weixugc@...gle.com
Subject: Re: [PATCH 00/10] [v7][RESEND] Migrate Pages in lieu of discard

Hi, Michal,

Michal Hocko <mhocko@...e.com> writes:

[...]

>> 
>> > Btw. do you have any numbers from running this with some real work
>> > workload?
>> 
>> Yes, quite a bit.  Do you have a specific scenario in mind?  Folks seem
>> to come at this in two different ways:
>> 
>> Some want to know how much DRAM they can replace by buying some PMEM.
>> They tend to care about how much adding the (cheaper) PMEM slows them
>> down versus (expensive) DRAM.  They're making a cost-benefit call
>> 
>> Others want to repurpose some PMEM they already have.  They want to know
>> how much using PMEM in this way will speed them up.  They will basically
>> take any speedup they can get.
>> 
>> I ask because as a kernel developer with PMEM in my systems, I find the
>> "I'll take what I can get" case more personally appealing.  But, the
>> business folks are much more keen on the "DRAM replacement" use.  Do you
>> have any thoughts on what you would like to see?
>
> I was thinking about typical large in memory processing (e.g. in memory
> databases) where the hot part of the working set is only a portion and
> spilling over to a slower memory can be still benefitial because IO +
> data preprocessing on cold data is much slower.

We have tested the patchset with the postgresql and pgbench.  On a
machine with DRAM and PMEM, the kernel with the patchset can improve the
score of pgbench up to 22.1% compared with that of the DRAM only + disk
case.  This comes from the reduced disk read throughput (which reduces
up to 70.8%).

Best Regards,
Huang, Ying

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ