public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: Carlos O'Donell <carlos@redhat.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Bumping _SC_GET*_R_SIZE_MAX to 4096?
Date: Sat, 11 Jul 2015 01:26:00 -0000	[thread overview]
Message-ID: <20150711012623.GX1173@brightrain.aerifal.cx> (raw)
In-Reply-To: <559FC12E.2030904@redhat.com>

On Fri, Jul 10, 2015 at 08:57:18AM -0400, Carlos O'Donell wrote:
> Over the years I've seen requests to bump
> the _SC_GET*_R_SIZE_MAX constant from 1024
> to 4096. Apparently there are systems where
> the smaller buffer always forces a reallocation
> and I'm told that Mac OSX already uses 4096
> for these constants.

When you say "systems", what exactly do you mean? Are there whole
classes of glibc deployments that need a larger buffer size for some
reason? Or is it just an issue for sites with huge gecos fields or
something?

Given how expensive these lookup operations themselves are, I think
the reallocation itself is negligible. However, if the whole operation
has to be repeated because of unsufficient output buffer space, that's
unfortunate and effectively doubles the lookup time. (Whether this is
the case probably depends on whether nscd is in use...?)

> Are there any implications, other than increased
> application memory usage?

I don't think so, but the proposed increase in memory usage is
somewhat substantial, especially for small systems. Maybe this doesn't
matter in environments where glibc is used/useful, though.

Rich

      reply	other threads:[~2015-07-11  1:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 12:58 Carlos O'Donell
2015-07-11  1:26 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150711012623.GX1173@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).