This is the mail archive of the 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: Seeking consensus on BZ 16734

On Wed, Feb 11, 2015 at 02:34:31PM +0100, Florian Weimer wrote:
> On 02/02/2015 06:14 AM, Rich Felker wrote:
> > On Sun, Feb 01, 2015 at 08:46:06PM -0800, Paul Pluzhnikov wrote:
> >> On Sun, Feb 1, 2015 at 8:09 PM, H.J. Lu <> wrote:
> >>
> >>>> Can we just do it?
> >>>>
> >>>
> >>> Do we have any current performance data on this?
> >>
> >> I am not sure what performance data you want.
> >>
> >> The application CPU will go up (calloc has to zero out space), kernel
> >> CPU will go down (kernel would not have to zero out the same space).
> >>
> >> It's clear that calloc()ing 8K is much cheaper than mmap()ing,
> >> especially when there are 100s of threads.
> > 
> > The original idea seems to be some misguided idea that read/write
> > should perform better with a page-aligned buffer.
> Historically, some Linux VFS read implementations could transfer the
> data by mapping full pages (/dev/zero was one of them).  I think they
> have been gone for a long time because you need to copy lots and lots of
> data (certainly more than 8K) before you lose against remapping and the
> cache invalidation that comes with it.

This seems like it would break horribly when the destination is
anything but anonymous memory (presumably they checked that) and would
perform atrociously bad (cost of locking vmas, possible TLB
invalidation, etc.) especially when the size of the read is at most a
few pages (which is the case for FILE buffers under normal usage). So
it seems like, even if such a hack were possible, it was terribly
misguided and would have pessimized performance for stdio.


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