linux-kernel - Re: [PATCH 0/3 v3] dcache: make it more scalable on large system

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: <1369846992.2769.149.camel@willson.li.ssimo.org>
Date:	Wed, 29 May 2013 13:03:12 -0400
From:	Simo Sorce <simo@...hat.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Waiman Long <waiman.long@...com>,
	Dave Chinner <david@...morbit.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Jeff Layton <jlayton@...hat.com>,
	Miklos Szeredi <mszeredi@...e.cz>, Ian Kent <raven@...maw.net>,
	Sage Weil <sage@...tank.com>, Steve French <sfrench@...ba.org>,
	Trond Myklebust <Trond.Myklebust@...app.com>,
	Eric Paris <eparis@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, autofs@...r.kernel.org,
	ceph-devel@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-nfs@...r.kernel.org,
	"Chandramouleeswaran, Aswin" <aswin@...com>,
	"Norton, Scott J" <scott.norton@...com>
Subject: Re: [PATCH 0/3 v3] dcache: make it more scalable on large system

On Wed, 2013-05-29 at 18:56 +0200, Andi Kleen wrote:
> On Wed, May 29, 2013 at 12:18:09PM -0400, Simo Sorce wrote:
> > On Wed, 2013-05-29 at 11:55 -0400, Waiman Long wrote:
> > 
> > > My patch set consists of 2 different changes. The first one is to avoid 
> > > taking the d_lock lock when updating the reference count in the 
> > > dentries. This particular change also benefit some other workloads that 
> > > are filesystem intensive. One particular example is the short workload 
> > > in the AIM7 benchmark. One of the job type in the short workload is 
> > > "misc_rtns_1" which calls security functions like getpwnam(), 
> > > getpwuid(), getgrgid() a couple of times. These functions open the 
> > > /etc/passwd or /etc/group files, read their content and close the files. 
> > > It is the intensive open/read/close sequence from multiple threads that 
> > > is causing 80%+ contention in the d_lock on a system with large number 
> > > of cores.
> > 
> > To be honest a workload base on /etc/passwd or /etc/group is completely
> > artificial, in actual usage, if you really have  such access you use
> > nscd or sssd with their shared memory caches to completely remove most
> > of the file access.
> 
> I don't fully agree at this point. A lot of things can be tuned away,
> but in practice we want things to perform well out of the box without
> needing all kinds of magic tuning that only 

Phrase seem cut mid-sentence ?

> Also this is just normal file access, nothing special about it.
> It simply has to scale. For all kinds of workloads.
> 
> And it does, just d_path messes it up.

Well there are reasonable workloads and artificial ones, I am just
warning not to use 'that' specific test as a good indicator, if you have
other reasonable workloads that show a similar flow feel free to bring
it up.

> > I have no beef on the rest but repeated access to Nsswitch information
> > is not something you need to optimize at the file system layer and
> > should not be brought up as a point in favor.
> 
> This is about repeated access to arbitrary files.

Ok. I do not want to start a discussion on this, I just pointed out the
specific point was not really a good example hopefully there are others
that justify the patchset.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

--
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/