linux-kernel - Re: [take21 0/4] kevent: Generic event handling mechanism.

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20061107113400.880e1ce9.akpm@osdl.org>
Date:	Tue, 7 Nov 2006 11:34:00 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Evgeniy Polyakov <johnpol@....mipt.ru>,
	David Miller <davem@...emloft.net>,
	Ulrich Drepper <drepper@...hat.com>,
	netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...l.org>
Subject: Re: [take21 0/4] kevent: Generic event handling mechanism.

On Tue, 07 Nov 2006 07:32:20 -0500
Jeff Garzik <jeff@...zik.org> wrote:

> Evgeniy Polyakov wrote:
> > Mmap ring buffer implementation was stopped by Andrew Morton and Ulrich
> > Drepper, process' memory is used instead. copy_to_user() is slower (and
> > some times noticebly), but there are major advantages of such approach.
> 
> 
> hmmmm.  I say there are advantages to both.

My problem with the old mmapped ringbuffer was that it permitted each user
to pin (typically) 48MB of unswappable memory.  Plus this pinned-memory
problem would put upper bounds on the ring size.

> Perhaps create a "kevent_direct_limit" resource limit for each thread. 
> By default, each thread could mmap $n pinned pagecache pages.  Sysadmin 
> can tune certain app resource limits to permit more.
> 
> I would think that retaining the option to avoid copy_to_user() 
> -somehow- in -some- cases would be wise.

What Evgeniy means here is that copy_to_user() is slower than memcpy() (on
his machine, with his kernel config, at least).

Which is kinda weird and unexpected and is something which we should
investigate independently from this project.  (Rather than simply going
and bypassing it!)

-
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/