User1: User2 i don't think that the wireless driver is related to the gpu driver.
User1: User2 rather, i've noticed your issue on the .31 kernels, specifically whenever the system begins running out of memory, or during periods of very high I/O activity
User2: oh i dont think the drivers are touching each other, just that X was going nuts until the wireless wanted so much CPU that they couldnt both have what they wanted
User1: O_o?
User2: well they both wanted to use 100% of CPU and kmail wanted 40%
User2: with a dual core, they can only get 200%
User1: kmail is an x client.
User1: but seriously, this isn't within ubuntu-x's field
User1: you should be complaining to the kde people
User1: ubuntu-x only handles X itself, and its drivers.
User2: *sigh* but the Xorg process was using 100% and then 58% later
User2: i already talked to rtg about the wireless thing, im just concerned about why Xorg is using my entire CPU when there's not even compositing happening
User1: O_o sounds like you seriously got your system screwed up
User2: i just installed it like 3 weeks ago
User1: but there are X clients that can cause Xorg's CPU usage to rise dramatically
User2: but kmail and Xorg are listed separately in top
User1: yes they are
User1: they are different processes
User2: and Xorg was using quite a lot more than kmail was
User1: but kmail is an X client
 * hyperair facepalm
User1: will you listen?
User1: quit kmail and see
User2: but kmail doesnt count into it!
User1: for all you know, kmail's causing X's CPU usage to rise
User2: it is not
User1: X clients *communicate* with the X server.
User2: xorg's usage has gone down since then
User2: Xorg process is down to 4% now (yay)  and kmail is still 31%
User1: well next time identify the faulty X client
User2: so Xorg's CPU usage in top isnt just adding up all the X clients' usage %s
User2: im running all the same things i was runnign before
User1: ...you seriously aren't listening.
User1: Xorg is a *server*. Kmail and other applications are X *clients*
User1: when a client bombards a server with requests, what happens?
User1: the server takes more CPU.
User1: it's as simple as that.
User1: they are separate processes!
User1: hell they could even be on different computers!
User2: so how do i find out which client is sending all those requests?
User2: the same apps have been running the entire time.
User1: dunno. quit the highest cpu using client and see
User1: could be a buggy client that suddenly screwed up
User2: if an application is on a different workspace, does it still talk to X? it doesnt need to be drawn...
User1: yes, it does.
User2: so if a terminal has an ssh session and that session is compiling stuff, X still would be requested to render all that compiler-spew?
User2: oh and the terminal is on a different workspace
User2: a not-visible one
User1: it would probably be telling X that there are updates
User1: but i don't think it would be rendered until it's unobscured
User2: hmm so could that be why my cpu usage goes up when im remote compiling?
User1: well it might rise a little, but very little.
User1: you should probably just test quitting the clients one by one the next time it happens
User2: ok
User3: hyperair is right
User2: im sorry i got confused before. the server & client separation didnt occur to me. i thought it was a parent/child process thing he was talking aout
User3: maco, xrestop can also give some clues about what apps might be using X, but it looks only at resource memory usage so isn't a perfect indicator
User2: how many *top apps are there?
User2: [h]top, powertop, and iotop were the ones i knew
User3: there's like a dozen
User3: htop, vtop, ptop, itop, atop, mtop, ntop, top, xrestop... probably lots more.  'stop' ;-)
User3: maco, anyway, it's a common point of confusion, and I've documented it at http://wiki.ubuntu.com/X/Troubleshooting/
User2: ok
User2: thanksguys
User3: Sarvatt, if you're interested in scoring some merges for your motu app, I've marked some packages currently needing merged:  http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html
User4: User3 Give away the hard ones....
User3: ScottK, I don't want to scare him off!  ;-)
User5: bryce, what do you think of this? http://ubuntuforums.org/showpost.php?p=7773647&postcount=13
User5: would the license allow this?
User6: User5 the patch acts upon the open part of the driver therefore I don't that patch is a problem
User5: can karmic ship with it?
User6: poulsbo was only made available in a PPA
User6: Ubuntu doesn't have poulsbo in its repositories
User6: as poulsbo uses an old version of libdrm
User6: a PPA would be the right place for that
User4: User6 PPA is only allowed for free software.
User5: ppa doesn't allow binary blobs?
User5: since when?
User6: User4 I know that nvidia is also made available in PPAs and there's this PPA with psb too: https://launchpad.net/~ubuntu-mobile/+archive/ppa
User4: User6 Read the PPA terms of service.
User7: maybe canonical gets an exception
User4: It probably does as there are commercial exceptions to the TOS.
User6: it could be
User5: does a driver have to be sanctioned in order to be included?
User5: also, even if intel and powervr had up to date psb drivers, would they be included by default?
User5: or would it be restricted?
User6: restricted
User6: not that it's so simple
User5: poulsbo's successor is likely to be another powervr-created monster.
User7: sigh.  they didn't learn anything from the psb fiasco?
User5: dunno.
User5: it was a decent chip spec-wise
User5: drivers were shit though.
User5: windows was no exception.
ubuntu-x
Ubuntu IRC