RE: Postal 56% waits for flock_lock_file_wait

[Trond Myklebust]

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@xxxxxxxxxx] 
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/