Re: PATCH/RFC: Bring lin-lwp performance back to the real world

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Nov 21, 2002 at 11:51:01PM -0500, Andrew Cagney wrote:
> > - It's such a wonderful bandaid that a lot of the badly needed
> >   cleanups may lose momentum.
> 
> ``Don't you worry about that'' :-)
> 
> A back of envelope calculation shows:
> 
> >Plucking a ``random'' memory location out of thin air:
> >
> >cagney@torrens$ grep 0x40040ea0 gdb.strace | grep ptrace | wc -l
> >   7038
> 
> For <160 stops, GDB fetched a thread-db buffer 7000 times.  So, GDB is 
> fetching an identical buffer 7000/160 ~= 50 times for every stop!
> 
> >cagney@torrens$ expr 7038 \* 250
> >1759500
> 
> 250?  I happen to know that the buffer is ~1000 bytes long which gives 
> us 250 (1000/sizeof(long) ptrace() calls for every buffer transfer.
> 
> The patch addresses the second problem, but not the first.  While it 
> releaves a bit of steam, there is still plenty of oportunity to further 
> ramp up the performance by several more orders of magnitude.
> 
> (BTW, this sort of brain-deadness on the part of GDB explains why other 
> minor performance tweeks had zero benefit :-)
> 
> ----
> 
> Note that the other /proc trickery is in linux-proc.c.  Should this be 
> there?

Hrm, possibly.  I needed to create linux-nat.c anyway (I'll need it for
some things that are definitely not /proc related) but I could be
persuaded either way on linux_proc_xfer_memory.  It's not focused on
the "proc" bit as much as the "xfer" bit, but it's definitely using
/proc.  If you prefer I'll move it, and save linux-nat.c for another
patch.

Thanks for the pointer to pread.  I don't know how far back it's
available... looks like 1997-09-30 in glibc.  Could just assume
pread64 and force -D_LARGEFILE64_SOURCE, I think - it's been there in
all of glibc2 and libc4/libc5 are pretty darned niche now.  Could
autoconf for it instead, easy enough...

I think I'll update the patch to autoconf check for pread64 with
appropriate compilation flags, and fall back to 32-bit lseek/read.
I'll repost it after I decide what to do about linux-proc vs linux-nat,
and any other comments come in (i.e. not tonight!).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer