lkml.org 
[lkml]   [2004]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.6.8.1-ck4
Date
Prakash K. Cheemplavam writes:
> |>> version of ck exhibited this, but the last one for 2.6.7 did work well
> |>> (I think even the one for 2.8.6-rc4 was ok), IIRC. In my case, when
> |>> doing a (niced) compile in background, some windows react very slow, ie
> |>> Mozilla Thunderbird takes ages to switch trough mails or cliking on an
> |>> icon in kde to load up konsole takes about 10seconds or more (shoud come
> |>> up <1sec normally).

> |>>> |> For both of you this only happens with NFS? Can you reproduce the
> |> problem in flight and send me the output of 'top -n -n 1' while it's
> |> happening? Also if you have time can you confirm this happens with
> |> just the staircase patch and none of the other patches?
> |
> |
> | blah... I mean `top -b -n 1`
>
> SO exactly what I observed, even with the latest test fix. In my first
> try the machin did even do a hard lock...
>
> So I did a emerge -B xorg-x11 (ie. I started compiling xorg-x11 using
> gentoo's emerge system). The hard lock occured after a minute or so.
> Next try I waited only a bit. I clicked on konsole icon to come up, but
> doesn't want to come for too long. In this time I did the top you see.
> I'll boot up linux-2.6.8-rc4 and test again (must check first whether it
> has reiser4 support...). I will also try to back oput staircase and try
> without.
>
> As you can see xorg-x11 wasn't really compiling ie not using cpu, it was
> just scaning through the directories to find it it has nothing to do:

Does it happen without nfs or not? Does it happen with only the staircase
patch or not?

> light@tachyon ~ $ top -b -n 1
> top - 11:22:41 up 4 min, 4 users, load average: 2.03, 1.20, 0.51
> Tasks: 94 total, 4 running, 90 sleeping, 0 stopped, 0 zombie
> Cpu(s): 7.4% us, 17.3% sy, 25.2% ni, 25.8% id, 23.6% wa, 0.1% hi, 0.6% si
> Mem: 1034224k total, 646380k used, 387844k free, 39220k buffers
> Swap: 0k total, 0k used, 0k free, 467460k cached

You're not hitting swap.

>
> ~ PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> ~ 5491 root 20 0 151m 20m 141m S 9.9 2.0 0:10.99 X

X is as good priority as it gets.

> ~ 5662 light 20 0 31616 15m 28m S 4.0 1.5 0:01.32 kdeinit
> 14859 light 20 0 31152 14m 28m R 2.0 1.5 0:00.33 kdeinit

So is kde

> ~ 44 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kswapd0

kswapd isn't chewing up cpu time.

In fact nothing is chewing up a lot of cpu time; you're just waiting on i/o

> Cpu(s): 7.4% us, 17.3% sy, 25.2% ni, 25.8% id, 23.6% wa, 0.1%
hi, 0.6% si

You even have 25% idle time so you have cpu to spare. Doesn't sound like a
scheduling issue but something getting stuck during I/O.

Something else is at play here. I need more information about
the questions above.

Con

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.037 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site