linux-kernel - Re: [PATCH v4] page_alloc: consider highatomic reserve in watermark fast

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]

Date:   Tue, 23 Jun 2020 09:11:25 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Mel Gorman <mgorman@...e.de>
Cc:     Mel Gorman <mgorman@...hsingularity.net>,
        ????????? <jaewon31.kim@...sung.com>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "bhe@...hat.com" <bhe@...hat.com>,
        "minchan@...nel.org" <minchan@...nel.org>,
        "hannes@...xchg.org" <hannes@...xchg.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jaewon31.kim@...il.com" <jaewon31.kim@...il.com>,
        ????????? <ytk.lee@...sung.com>,
        ????????? <cmlaika.kim@...sung.com>
Subject: Re: [PATCH v4] page_alloc: consider highatomic reserve in watermark
 fast

On Mon 22-06-20 17:25:01, Mel Gorman wrote:
> On Mon, Jun 22, 2020 at 04:23:04PM +0200, Michal Hocko wrote:
> > On Mon 22-06-20 11:04:39, Mel Gorman wrote:
> > > On Mon, Jun 22, 2020 at 06:40:20PM +0900, ????????? wrote:
> > > > >But more importantly, I have hard time to follow why we need both
> > > > >zone_watermark_fast and zone_watermark_ok now. They should be
> > > > >essentially the same for anything but order == 0. For order 0 the
> > > > >only difference between the two is that zone_watermark_ok checks for
> > > > >ALLOC_HIGH resp ALLOC_HARDER, ALLOC_OOM. So what is exactly fast about
> > > > >the former and why do we need it these days?
> > > > > 
> > > > 
> > > > I think the author, Mel, may ansewr. But I think the wmark_fast may
> > > > fast by 1) not checking more condition about wmark and 2) using inline
> > > > rather than function. According to description on commit 48ee5f3696f6,
> > > > it seems to bring about 4% improvement.
> > > > 
> > > 
> > > The original intent was that watermark checks were expensive as some of the
> > > calculations are only necessary when a zone is relatively low on memory
> > > and the check does not always have to be 100% accurate. This is probably
> > > still true given that __zone_watermark_ok() makes a number of calculations
> > > depending on alloc flags even if a zone is almost completely free.
> > 
> > OK, so we are talking about 
> > 	if (alloc_flags & ALLOC_HIGH)
> > 		min -= min / 2;
> > 
> > 	if (unlikely((alloc_flags & (ALLOC_HARDER|ALLOC_OOM))) {
> > 		/*
> > 		 * OOM victims can try even harder than normal ALLOC_HARDER
> > 		 * users on the grounds that it's definitely going to be in
> > 		 * the exit path shortly and free memory. Any allocation it
> > 		 * makes during the free path will be small and short-lived.
> > 		 */
> > 		if (alloc_flags & ALLOC_OOM)
> > 			min -= min / 2;
> > 		else
> > 			min -= min / 4;
> > 	}
> > 
> > Is this something even measurable and something that would justify a
> > complex code? If we really want to keep it even after these changes
> > which are making the two closer in the cost then can we have it
> > documented at least?
> 
> It was originally documented as being roughly 4% for a page allocator
> micro-benchmark but that was 4 years ago and I do not even remember what
> type of machine that was on. Chances are the relative cost is different
> now but I haven't measured it as the microbenchmark in question doesn't
> even compile with recent kernels.

Thanks for the clarification.

> For many allocations, the bulk of the
> allocation cost is zeroing the page so I have no particular objection
> to zone_watermark_fast being removed if it makes the code easier to
> read. While I have not looked recently, the cost of allocation in general
> and the increasing scope of the zone->lock with larger NUMA nodes for
> high-order allocations like THP are more of a concern than two branches
> and potentially two minor calculations.

OK, then I would rather go with the code simplification for the future
maintainability. If somebody can test this and provide good numbers then
we can reintroduce a fast check.

Thanks!
-- 
Michal Hocko
SUSE Labs