Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-30 Thread Brian F. Feldman
Time for this oppressed person to go ln -s H /etc/malloc.conf... Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-30 Thread Matthew Dillon
:In any case, the man page for malloc/free explains how to change :the default, if you're a part of the "oppressed" 1%. : :Alan Not with a gig of memory :-). My only concern is for the performance curve to look good and not be too jagged. -Matt

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-30 Thread Alan Cox
On Fri, Jul 30, 1999 at 09:51:35AM -0700, Matthew Dillon wrote: > > I'm not sure I see how MADV_FREE could slow performance down unless, > perhaps, it is the overhead of the system call itself. e.g. if malloc > is calling it on a page-by-page basis and not implementing any hysteresis.

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-30 Thread Brian F. Feldman
Time for this oppressed person to go ln -s H /etc/malloc.conf... Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |__

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-30 Thread Matthew Dillon
:In any case, the man page for malloc/free explains how to change :the default, if you're a part of the "oppressed" 1%. : :Alan Not with a gig of memory :-). My only concern is for the performance curve to look good and not be too jagged. -Matt

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-30 Thread Alan Cox
On Fri, Jul 30, 1999 at 09:51:35AM -0700, Matthew Dillon wrote: > > I'm not sure I see how MADV_FREE could slow performance down unless, > perhaps, it is the overhead of the system call itself. e.g. if malloc > is calling it on a page-by-page basis and not implementing any hysteresis.

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-30 Thread Matthew Dillon
:Your new "behavior" flag isn't known by vm_map_simply_entry, so :map simplification could drop the behavior setting on the floor. :I would prefer that the behavior is folded into eflags. : :Overall, I agree with the direction. Behavior is correctly a map :attribute rather than an object attribut

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-30 Thread Matthew Dillon
:Your new "behavior" flag isn't known by vm_map_simply_entry, so :map simplification could drop the behavior setting on the floor. :I would prefer that the behavior is folded into eflags. : :Overall, I agree with the direction. Behavior is correctly a map :attribute rather than an object attribu

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-29 Thread Alan Cox
Your new "behavior" flag isn't known by vm_map_simply_entry, so map simplification could drop the behavior setting on the floor. I would prefer that the behavior is folded into eflags. Overall, I agree with the direction. Behavior is correctly a map attribute rather than an object attribute.

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-29 Thread Alan Cox
Your new "behavior" flag isn't known by vm_map_simply_entry, so map simplification could drop the behavior setting on the floor. I would prefer that the behavior is folded into eflags. Overall, I agree with the direction. Behavior is correctly a map attribute rather than an object attribute.

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-29 Thread Matthew Dillon
:extremely well. So well, in fact, that I can have a program which :mmap()'s a large file and continuously scans it - generating 4MB/sec of :network traffic, with virtually no effect to the rest of the system. Oh, clarification: continuously scans it but also calls madvise(.

Re: patch for behavior changes and madvise MADV_DONTNEED

1999-07-29 Thread Matthew Dillon
:extremely well. So well, in fact, that I can have a program which :mmap()'s a large file and continuously scans it - generating 4MB/sec of :network traffic, with virtually no effect to the rest of the system. Oh, clarification: continuously scans it but also calls madvise(