This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: horrible disk thorughput on itanium


> Cc: libc-alpha@sources.redhat.com
> From: Andreas Jaeger <aj@suse.de>
> Date: Fri, 07 Dec 2001 20:13:37 +0100

> I'm bringing over this discussion from linux-kernel to libc-alpha, I'm
> not CC'ing linux-kernel anymore since that list is irrelevant for this
> topic.
> 
> torvalds@transmeta.com (Linus Torvalds) writes:
> 
> > In article <Pine.LNX.4.33.0112070710120.747-100000@mikeg.weiden.de>,
> > Mike Galbraith  <mikeg@wen-online.de> wrote:
> >>
> >>> Andrew Morton <akpm@zip.com.au> writes:
> >>>
> >>> As far as I can see bonnie++ doesn't use putc_unlocked, but putc.
> >>
> >>Plain old Bonnie suffered from the same thing.  I long ago made it
> >>use putc_unlocked() here because throughput was horrible otherwise.
> >
> > Oh, yeah, blame it on bonnie.
> >
> > 	"Our C library 'putc' is horribly sucky"
> >
> > 	"Well, then, use something else then".
> >
> > Isn't somebody ashamed of glibc and willing to try to fix it? It might
> > be as simple as just testing a static flag "have I used pthread_create"
> > or even a function pointer that gets switched around at pthread_create..
> 
> This should be doable.  We could easily implement libio/putc.c as
> follows:
> 
> extern void __pthread_initialize (void) __attribute__ ((weak));
> 
> int
> _IO_putc (c, fp)
>      int c;
>      _IO_FILE *fp;
> {
>   if (__pthread_initialize != NULL)
>     {
>       int result;
>       CHECK_FILE (fp, EOF);
>       _IO_cleanup_region_start ((void (*) __P ((void *))) _IO_funlockfile, fp);
>       _IO_flockfile (fp);
>       result = _IO_putc_unlocked (c, fp);
>       _IO_funlockfile (fp);
>       _IO_cleanup_region_end (0);
>       return result;
>     }
>   return _IO_putc_unlocked (c, fp);
> }
> 
> The cost for code that is linked against libpthread is an extra
> comparison.  Code that does not use libpthread will be faster since we
> don't need to do the locking.
> 
> As an alternative we could used instead of __pthread_initialize a symbol:
> weak_extern (__pthreads_in_use)
> 
> and set this in pthread_create.
> 
> What do others think?  Shall I send a complete patch?

Is this really much faster?  I'd think that, when there is no
contention, locking and unlocking a FILE structure should be about as
expensive as loading a symbol and comparing it to zero.  Is the
cleanup stuff very expensive?

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]