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] [day] [month] [year] [list]
Message-ID: <20170310144539.GK3753@dhcp22.suse.cz>
Date:   Fri, 10 Mar 2017 15:45:39 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Mel Gorman <mgorman@...e.de>
Cc:     Zi Yan <zi.yan@...rutgers.edu>,
        David Nellans <dnellans@...dia.com>,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, vbabka@...e.cz,
        minchan@...nel.org, aneesh.kumar@...ux.vnet.ibm.com,
        bsingharora@...il.com, srikar@...ux.vnet.ibm.com,
        haren@...ux.vnet.ibm.com, jglisse@...hat.com,
        dave.hansen@...el.com, dan.j.williams@...el.com,
        Naoya Horiguchi <n-horiguchi@...jp.nec.com>
Subject: Re: [PATCH 0/6] Enable parallel page migration

On Fri 10-03-17 14:07:16, Mel Gorman wrote:
> On Thu, Mar 09, 2017 at 05:46:16PM -0600, Zi Yan wrote:
[...]
> > I understand your concern on CPU utilization impact. I think checking
> > CPU utilization and only using idle CPUs could potentially avoid this
> > problem.
> > 
> 
> That will be costly to detect actually. It would require poking into the
> scheduler core and incurring a number of cache misses for a race-prone
> operation that may not succeed. Even if you do it, it'll still be
> brought up that the serialised case should be optimised first.

do not forget that seeing idle cpus is not a sufficient criterion to use
it for parallel migration. There might be other policies you are not
aware of from the MM code to keep them idle (power saving and who knows
what else). Developing a reasonable strategy for spreading the load to
different CPUs is really hard, much harder than you can imaging I
suspect (just look at how hard it was and I long it took to get to a
reasonable scheduler driven frequency scaling/power governors).
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ