linux-kernel - Re: [take19 1/4] kevent: Core files.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-id: <4535B16F.7080208@cosmosbay.com>
Date:	Wed, 18 Oct 2006 06:45:35 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	Johann Borck <johann.borck@...sedata.com>,
	Ulrich Drepper <drepper@...hat.com>,
	Ulrich Drepper <drepper@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
	Zach Brown <zach.brown@...cle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Chase Venters <chase.venters@...entec.com>
Subject: Re: [take19 1/4] kevent: Core files.

Evgeniy Polyakov a e'crit :
> On Tue, Oct 17, 2006 at 06:45:54PM +0200, Eric Dumazet (dada1@...mosbay.com) wrote:
>> I am not sure I understand what you wrote, English is not our native language.
>>
>> I think many people gave you feedbacks. I feel that all feedback on this 
>> mailing list is constructive. Many posts/patches on this list are never 
>> commented at all.
> 
> And I do greatly appreciate feedback from those people!
> 
> But I do not understand why I never got feedback on initial design and
> implementation (and then created as far as I recall at least 10
> releases) from Ulrich, who first asked for such a feture. 
> So right now I'm waiting for his opinion on that problem, even if it will 
> be 'it sucks' again, but at least in that case I will not waste people's time.
> 
> Ulrich, could you please comment on design notes sent couple of mail
> above?


Ulrich is a very busy man. We have to live with that.

<rant_mode>
For example, I *complained* one day, that each glibc fopen()/fread()/fclose() 
pass does a mmap()/munmap() to obtain a single 4KB of memory, without any 
cache mechanism. This badly hurts performance of multi-threaded programs as we 
know mmap()/munmap() has to down_write(&mm->mmap_sem); and play VM games.

So to avoid this, I manually call setvbuf() in my own programs, to provide a 
suitable buffer to glibc, because of its suboptimal default allocation, 
vestige of an old epoch...
</rant_mode>

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/