Re: [take6 1/3] kevent: Core files.

2006-08-11 Thread Evgeniy Polyakov
On Fri, Aug 11, 2006 at 12:04:54AM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > > This area can be decreased down to 70mb by reducing amount of > > information placed into the buffer (only user's data and flags) without > > additional hints. > > > > 70MB is still very bad, naturally. Actua

Re: [take6 1/3] kevent: Core files.

2006-08-11 Thread Andrew Morton
On Fri, 11 Aug 2006 10:30:21 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > On Thu, Aug 10, 2006 at 11:23:40PM -0700, Andrew Morton ([EMAIL PROTECTED]) > wrote: > > On Fri, 11 Aug 2006 10:15:35 +0400 > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > On Thu, Aug 10, 2006 at 05:56:39P

Re: [take6 1/3] kevent: Core files.

2006-08-11 Thread Evgeniy Polyakov
On Thu, Aug 10, 2006 at 11:38:26PM -0700, David Miller ([EMAIL PROTECTED]) wrote: > From: Evgeniy Polyakov <[EMAIL PROTECTED]> > Date: Fri, 11 Aug 2006 10:33:53 +0400 > > > That requires mmap hacks to substitute pages in run-time without user > > notifications. I do not expect it is a good soluti

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread David Miller
From: Evgeniy Polyakov <[EMAIL PROTECTED]> Date: Fri, 11 Aug 2006 10:33:53 +0400 > That requires mmap hacks to substitute pages in run-time without user > notifications. I do not expect it is a good solution, since on x86 it > requires full TLB flush (at least when I did it there were no exported

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Evgeniy Polyakov
On Thu, Aug 10, 2006 at 11:25:05PM -0700, Ulrich Drepper ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > > The main disadvantage is that all memory is allocated on the start even > > if it will not be used later. I think dynamic grow is appropriate > > solution, since user will have that me

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Ulrich Drepper
Evgeniy Polyakov wrote: > The main disadvantage is that all memory is allocated on the start even > if it will not be used later. I think dynamic grow is appropriate > solution, since user will have that memory used anyway, since kevents > are allocated, If you _allocate_ memory at startup you're

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Evgeniy Polyakov
On Thu, Aug 10, 2006 at 11:23:40PM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > On Fri, 11 Aug 2006 10:15:35 +0400 > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > On Thu, Aug 10, 2006 at 05:56:39PM -0700, Andrew Morton ([EMAIL PROTECTED]) > > wrote: > > > > Per kevent fd. > > > > I have

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Andrew Morton
On Fri, 11 Aug 2006 10:15:35 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > On Thu, Aug 10, 2006 at 05:56:39PM -0700, Andrew Morton ([EMAIL PROTECTED]) > wrote: > > > Per kevent fd. > > > I have some ideas about better mmap ring implementation, which would > > > dinamically grow it's buffer

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Evgeniy Polyakov
On Thu, Aug 10, 2006 at 05:56:39PM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > > Per kevent fd. > > I have some ideas about better mmap ring implementation, which would > > dinamically grow it's buffer when events are added and reuse the same > > place for next events, but there are some nit

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Andrew Morton
On Thu, 10 Aug 2006 12:22:35 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > On Thu, Aug 10, 2006 at 01:02:54AM -0700, Andrew Morton ([EMAIL PROTECTED]) > wrote: > > > > Afaict this mmap function gives a user a free way of getting pinned > > > > memory. > > > > What is the upper bound on th

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Evgeniy Polyakov
On Thu, Aug 10, 2006 at 01:02:54AM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > > > Afaict this mmap function gives a user a free way of getting pinned > > > memory. > > > What is the upper bound on the amount of memory which a user can thus > > > obtain? > > > > it is limited by maximum q

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Andrew Morton
On Thu, 10 Aug 2006 11:50:47 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > Afaict this mmap function gives a user a free way of getting pinned memory. > > What is the upper bound on the amount of memory which a user can thus > > obtain? > > it is limited by maximum queue length which is

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Evgeniy Polyakov
On Thu, Aug 10, 2006 at 12:18:44AM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > > > > + spin_lock_init(&k->ulock); > > > > + k->kevent_entry.next = LIST_POISON1; > > > > + k->storage_entry.prev = LIST_POISON2; > > > > + k->ready_entry.next = LIST_POISON1; > > > > > >

Re: [take6 1/3] kevent: Core files.

2006-08-10 Thread Andrew Morton
On Thu, 10 Aug 2006 10:14:33 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > + union { > > > + __u32 user[2];/* User's data. It is > > > not used, just copied to/from user. */ > > > + void*ptr; > > > + }; > > > +}; > > > > What is thi

Re: [take6 1/3] kevent: Core files.

2006-08-09 Thread Evgeniy Polyakov
On Wed, Aug 09, 2006 at 11:42:35PM -0700, David Miller ([EMAIL PROTECTED]) wrote: > > > > + k->kevent_entry.next = LIST_POISON1; > > > > + k->storage_entry.prev = LIST_POISON2; > > > > + k->ready_entry.next = LIST_POISON1; > > > > > > Nope ;) > > > > I use pointer checks to det

Re: [take6 1/3] kevent: Core files.

2006-08-09 Thread David Miller
From: Evgeniy Polyakov <[EMAIL PROTECTED]> Date: Thu, 10 Aug 2006 10:14:33 +0400 > On Wed, Aug 09, 2006 at 03:21:27PM -0700, Andrew Morton ([EMAIL PROTECTED]) > wrote: > > On big-endian machines, this pointer will appear to be word-swapped as far > > as a 64-bit kernel is concerned. Or something

Re: [take6 1/3] kevent: Core files.

2006-08-09 Thread Evgeniy Polyakov
On Wed, Aug 09, 2006 at 03:21:27PM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > On Wed, 9 Aug 2006 12:02:40 +0400 > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > Core files. > > > > This patch includes core kevent files: > > - userspace controlling > > - kernelspace interfaces >

Re: [take6 1/3] kevent: Core files.

2006-08-09 Thread David Miller
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 9 Aug 2006 10:47:38 -0700 > static wrapper_functions_with_execessive_long_names(struct i_really_hate > *this) > { > suck(); > } Yes, typing 50 characters just to bump a counter, it's beyond rediculious. Go hack on the X server if you

Re: [take6 1/3] kevent: Core files.

2006-08-09 Thread Andrew Morton
On Wed, 9 Aug 2006 12:02:40 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > Core files. > > This patch includes core kevent files: > - userspace controlling > - kernelspace interfaces > - initialization > - notification state machines > > It might also inlclude parts from other subsys

Re: [take6 1/3] kevent: Core files.

2006-08-09 Thread Evgeniy Polyakov
On Wed, Aug 09, 2006 at 10:47:38AM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: > > +static inline void kevent_user_stat_increase_total(struct kevent_user *u) > > +{ > > + u->total++; > > +} > > > > static wrapper_functions_with_execessive_long_names(struct i_really_hate > *this) > { >

Re: [take6 1/3] kevent: Core files.

2006-08-09 Thread Stephen Hemminger
On Wed, 9 Aug 2006 12:02:40 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > Core files. > > This patch includes core kevent files: > - userspace controlling > - kernelspace interfaces > - initialization > - notification state machines > > It might also inlclude parts from other subsys

[take6 1/3] kevent: Core files.

2006-08-09 Thread Evgeniy Polyakov
Core files. This patch includes core kevent files: - userspace controlling - kernelspace interfaces - initialization - notification state machines It might also inlclude parts from other subsystem (like network related syscalls, so it is possible that it will not compile without other patche