[buildd-tools-devel] Unresponsive mouse in X when compiling with schroot

[Helge Kreutzmann]

Hello Roger,
On Wed, Jul 22, 2009 at 04:45:20PM +0100, Roger Leigh wrote:
> On Wed, Jul 22, 2009 at 03:10:07PM +0200, Helge Kreutzmann wrote:
> 
> [poor responsiveness]
> 
> > Is there any experience in your team what setting might cause this? Is
> > there some way to "renice" the schroot (I don't mind longer
> > compilation times) so that the load on the system is reduced hence
> > keeping the mouse under X usable?
> 
> I can't say I've noticed this myself.  It's indicative of a high system
> load, but it's not clear from your description what the cause is.

Strange thing is, if I compile the same software outside the chroot
(using fakeroot) the load is approximately the same (around 1) and the
system is still responsive.

> Could you provide your schroot configuration for the chroot in
> question? (schroot --config -c <chroot>).

remaxp:~# schroot --config -c sid
# schroot-Konfiguration erzeugt von schroot 1.2.2 am 22. Juli 2009

[sid]
active=false
aliases=unstable,default
command-prefix=
description=Debian sid (unstable)
environment-filter=^(BASH_ENV|CDPATH|ENV|HOSTALIASES|IFS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMAIN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TERMPATH)$
groups=
location=/var/chroot/sid
personality=linux
priority=3
root-groups=
root-users=
run-exec-scripts=false
run-setup-scripts=false
script-config=script-defaults
type=plain
users=helge

> If it's an LVM snapshot and doing heavy writing, you might get the
> snapshot copy-on-write device doing some work.  For other chroot

I use LVM, but not snapshotting.

> types, other than the chroot() call, the system should behave
> *identically* to running the build outside the chroot.

Thats what I thought as well, and thats why I'm puzzled.

> To find the underlying cause, running top, iotop etc. to see what's
> causing the high load would be useful.

I often monitor the compile using htop, which showed (to my eyes) nothing
strange. The load was around 1 and I could see make and gcc running.
It looked fairly straight forward (haven't compared to the outside
compile due to strong differences like paths, gcc version etc.)

I just installed iotop, but probably will need to recompile my kernel:
- Linux >= 2.6.20 with I/O accounting support: Not found

> Renicing is certainly possible.  In your configuration
>   command-prefix=nice
> should do the trick.  However, command-prefix was originally
> written to just run a single command with no arguments--it
> might well not support arguments (originally added to prefix
> the command with linux32 prior to integrated personality support).

According to schroot.conf(5) it does accept arguments?  Anyhow, I can't
get it to work:
/usr/bin/nice: 10: File or directory not found

Since the compile is within a script, I tried adding the nice within 
that script, but
/usr/bin/nice 10 fakeroot ...  
neither works.

> I will be happy to update command-prefix to accept multiple args.
> Then you can get it to prefix your command with "nice -n <level>"

Well, if it'll work it would be great, otherwise I don't want to draw
your ressources to something which just as well might not work.

> Since schroot runs setuid root, we can call nice(2) directly
> before exec()ing the command.  We could add a nice=level parameter
> to the configuration file.  That's also a simple change which I
> would be happy to make.

If its simple, maybe you could "hack" it in and make it downloadable
somewhere (fine if in source, I can build it myself, using the
previous debian patch if possible).

> Since renicing is really only working around the poor performance,
> it would be great to find out in more detail what the underlying
> cause is, so we can (if possible) address that directly.

Yes. I guess the first step is to build a new kernel for running
iotop?

Thanks!

Greetings

         Helge
-- 
      Dr. Helge Kreutzmann                     debian at helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20090722/a7b00a03/attachment.pgp>