linux-kernel - RE: Postal 56% waits for flock_lock_file

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:	Sun, 01 Oct 2006 13:18:12 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	"Ananiev, Leonid I" <leonid.i.ananiev@...el.com>
Cc:	Linux Kernel Mailing List <Linux-Kernel@...r.kernel.org>
Subject: RE: Postal 56% waits for flock_lock_file_wait

On Sun, 2006-10-01 at 20:53 +0400, Ananiev, Leonid I wrote:
> > The kernel would appear to be doing exactly what is expected of it.
> 
> Each of 16 user threads calls to open() one of 1000 files each 20 sec.
> 3000 calls per minute in sum.
> The open() sleeps.

According to your numbers, the call to flock() sleeps. Where do they
show a measurable sleep in open()?

> I'm not sure that users expected just of sleeping.

I still don't get it. The job of the flock() system call is to sleep if
someone already holds the lock, and then grab the lock when it is
released. If that is not what the user expects, then the user has the
option of not calling flock(). This has nothing to do with open().

Trond


> Leonid
> 
> -----Original Message-----
> From: Trond Myklebust [mailto:trond.myklebust@....uio.no] 
> Sent: Sunday, October 01, 2006 8:05 AM
> To: Ananiev, Leonid I
> Cc: Linux Kernel Mailing List
> Subject: RE: Postal 56% waits for flock_lock_file_wait
> 
> On Sat, 2006-09-30 at 21:26 +0400, Ananiev, Leonid I wrote:
> > > On which filesystem were the above results obtained if it was not
> > ext2?
> > The default ext3 fs was used.
> > 
> > > All the above results are telling you is that your test involves
> > several
> > > processes contending for the same lock, and so all of them barring
> the
> > > one process that actually holds the lock are idle.
> > 
> > Yes. It is  flock_lock_file_wait.
> 
> That is the function which causes the sleep, yes. So what is your gripe?
> The kernel would appear to be doing exactly what is expected of it.
> 
> Trond

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