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]
Message-Id: <20100114151959.2c46ee79.akpm@linux-foundation.org>
Date:	Thu, 14 Jan 2010 15:19:59 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Wu Fengguang <fengguang.wu@...el.com>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	David Rientjes <rientjes@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Minchan Kim <minchan.kim@...il.com>,
	Huang Shijie <shijie8@...il.com>
Subject: Re: [resend][PATCH] mm: Restore zone->all_unreclaimable to
 independence word

On Thu, 14 Jan 2010 16:32:29 +0800
Wu Fengguang <fengguang.wu@...el.com> wrote:

> On Thu, Jan 14, 2010 at 03:14:10PM +0800, KOSAKI Motohiro wrote:
> > > On Thu, 14 Jan 2010, KOSAKI Motohiro wrote:
> > > 
> > > > commit e815af95 (change all_unreclaimable zone member to flags) chage
> > > > all_unreclaimable member to bit flag. but It have undesireble side
> > > > effect.
> > > > free_one_page() is one of most hot path in linux kernel and increasing
> > > > atomic ops in it can reduce kernel performance a bit.
> > > > 
> > > > Thus, this patch revert such commit partially. at least
> > > > all_unreclaimable shouldn't share memory word with other zone flags.
> > > > 
> > > 
> > > I still think you need to quantify this; saying you don't have a large 
> > > enough of a machine that will benefit from it isn't really a rationale for 
> > > the lack of any data supporting your claim.  We should be basing VM 
> > > changes on data, not on speculation that there's a measurable impact 
> > > here.
> > > 
> > > Perhaps you could ask a colleague or another hacker to run a benchmark for 
> > > you so that the changelog is complete?
> > 
> > ok, fair. although I dislike current unnecessary atomic-ops.
> > I'll pending this patch until get good data.
> 
> I think it's a reasonable expectation to help large boxes.
> 
> What we can do now, is to measure if it hurts mainline SMP
> boxes. If not, we are set on doing the patch :)

yup, the effects of the change might be hard to measure.  Not that one
shouldn't try!

But sometimes we just have to do a best-effort change based upon theory
and past experience.

Speaking of which...

: --- a/include/linux/mmzone.h
: +++ b/include/linux/mmzone.h
: @@ -341,6 +341,7 @@ struct zone {
:  
:  	unsigned long		pages_scanned;	   /* since last reclaim */
:  	unsigned long		flags;		   /* zone flags, see below */
: +	int                     all_unreclaimable; /* All pages pinned */
:  
:  	/* Zone statistics */
:  	atomic_long_t		vm_stat[NR_VM_ZONE_STAT_ITEMS];

Was that the best place to put the field?  It adds four bytes of
padding to the zone, hence is suboptimal from a cache utilisation point
of view.

It might also be that we can place this field closed in memory to other
fields which are being manipulated at the same time as
all_unreclaimable, hm?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ