On Mon, Aug 8, 2011 at 1:31 PM, Andres Freund <andres@anarazel.de> wrote:
> If its ok I will write a mail to lkml referencing this thread and your numbers
> inline (with attribution obviously).
That would be great. Please go ahead.
> I don't think it will be that hard to convince them. But I constantly surprise
> myself with naivity so I may be wrong.
Heh, heh, open source is fun.
>> > My largest machine I can reboot often enough to test such a thing has only
>> > two sockets (4cores E5520). I guess you cannot reboot your loaned machine
>> > with a new kernel easily?
>>Not really. I do have root access to a 64-core box at the moment, and
>>I could probably get permission to reboot it, but if it didn't come
>>back on-line that would be awkward.
> As I feared. Any chance that the person lending you the machine can give you a
> hand?
Uh, maybe, but considering my relative inexperience in compiling the
Linux kernel, I'd be a little worried about having to iterate too many
times.
> Although I don't know how that could be after reading the code it would be
> disappointing to wait for 3.2 with the llseek fixes appearing in $distribution
> just to notice fstat is still faster for $unobvious_reason...
Well, the good thing here is that we are really only concerned with
gross effects. It's pretty obvious from the numbers I posted upthread
that the problem is related to lock contention. If that gets fixed,
and lseek is still 20% slower under some set of circumstances, it's
not clear that we're really gonna care. I mean, maybe it would be
nice to avoid going to the kernel at all here just so we're immune to
possible inefficiencies in other operating systems (it would be nice
if someone could repeat these tests on a big SMP box running Windows
and/or one of BSD systems) and to save the overhead of a system call,
but those effects are pretty tiny. We could spend a lot of time
optimizing other things before that one percolated up to the top of
the heap, at least based on what I've seen so far.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company