lkml.org 
[lkml]   [2008]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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    [W:0.104 / U:20.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site