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

[Roger Leigh]

On Wed, Jul 22, 2009 at 06:15:29PM +0200, Helge Kreutzmann wrote:
> 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.

Are you using sbuild to build in the chroot, or are you building
using exactly the same command as outside?  (Not that this should
make a difference--but it's a possible source of variation.)

> > 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]
> location=/var/chroot/sid
> run-exec-scripts=false
> run-setup-scripts=false
> script-config=script-defaults
> type=plain

That's a very standard setup.  You aren't even doing any automatic
filesystem mounting with type=directory or running any setup
scripts.  With this setup, schroot should be equivalent to
"sudo /usr/sbin/chroot <command>", and shouldn't be causing any
extra overhead.

Do you see the same extra load or lack of responsiveness if using
/usr/sbin/chroot in place of schroot?

> 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 guess it depends on what causes the problem as to how this affects
the system load.  I think it's more likely to be I/O than CPU, but
both are a little odd, since it shouldn't be using any more than when
run on the host system.

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

Yes.  I'm using iotop on 2.6.29/2.6.30.

BTW, it's possible that this is a kernel issue with e.g. the
scheduler or something.  It might be worth trying a newer kernel
if you have the possibility of doing so.

> > 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

Ah, it's not doing a path search for nice, so you need to use
  command-prefix=/usr/bin/nice
or
  command-prefix=/usr/bin/nice,-n,15
to use a nice value of 15.  This is all working as designed, but I
should really get it to find the command in $PATH rather than
requiring an absolute path (as already done for the real command to
exec).

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

This should definitely work.  You might need "-n 10" rather than
just "10"

> > 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.

This should work as I described above; it just need to do a PATH
search to make it a bit more user-friendly.

> > 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).

I'll add this to the current development branch.  Since I think
the command-prefix trick should work for current releases, I'll
schedule this for a future release.  If you want it, I can
probably make a patch for current stable releases, though.

> > 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?

I think that would be a useful first step, though I'm afraid I
don't really have many more suggestions as to how to investigate
further than that.  It may be that linux-kernel or debian-devel
are better places with more expertise in this area, unless anyone
else on buildd-tools-devel has any better ideas?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.