lkml.org 
[lkml]   [2008]   [May]   [9]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 9 May 2008 08:50:32 +0200
FromIngo Molnar <>
SubjectRe: [patch] speed up / fix the new generic semaphore code (fix AIM7 40% regression with 2.6.26-rc1)
* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > I don't think fixing n_tty is now a big job if someone wants to take 
> > a swing at it. The driver write/throttle/etc routines below the 
> > n_tty ldisc layer are now BKL clean so it should just be the 
> > internal locking of the buffers, window and the like to tackle.
> 
> Well, it turns out that Ingo's fixed statistics actually put the real 
> cost in fcntl/ioctl/open/release:
> 
>     310  down <= lock_kernel <= sys_fcntl <= system_call_after_swapgs <
>     332  down <= lock_kernel <= vfs_ioctl <= do_vfs_ioctl <
>     380  down <= lock_kernel <= tty_release <= __fput <
>     422  down <= lock_kernel <= chrdev_open <= __dentry_open <
> 
> rather than the write routines. But it may be that Ingo was just 
> profiling two different sections, and it's really all of them.

the first trace had general desktop load mixed into it as well - so 
while it's not interesting to AIM7 the BKL does matter in those 
situations and i'd not be surprised if it was responsible for certain 
categories of desktop lag.

The second trace was the correct 'pure' AIM7 workload which produces 
very little tty output. It is a quite stable workload and the trace i 
uploaded is representative of the totality of that workload. AIM7 runs 
for several minutes so there's no significant rampup/rampdown 
interaction either.

	Ingo


\
 
 \ /
  Last update: 2008-05-09 08:53    [from the cache]
©2003-2008