On Tue, Jan 11, 2000 at 01:16:59AM +0100, Andrea Arcangeli wrote:
> On Mon, 10 Jan 2000, Zack Weinberg wrote:
>
> >On Mon, Jan 10, 2000 at 08:49:10PM +0100, Andrea Arcangeli wrote:
> >> On Sun, 9 Jan 2000, Zack Weinberg wrote:
> >>
> >> >+ && !(new = __get_free_pages(GFP_USER, order)))
> >>
> >> mm fragmentation and the VM not good in handling a fragmented mm is going
> >> to hurt you.
> >
> >I was under the impression __get_free_pages allocated physically contiguous
> >memory.
>
> Your impression is correct and that's the source of the mm fragmentation
> trouble.
Oh, you meant that allocating a huge buffer might cause problems elsewhere.
I don't think that was the cause of the entire slowdown, certainly not on
a 256MB machine with nothing else running.
> >Do you know how to limit the size of AF_UNIX packets? I would like to try
>
> You set it by hand: set sock opt SO_SNDBUF plus sysclt_*mem_max.
>
> For stream AF_UNIX sockets you fallback to 1 page if the allocation fails
> so you don't know. For dgram sockets you'll have to do the full allocation
> in one packet or you'll wait.
What I meant was, how to make a stream socket behave like a pipe and consume
only 4k at a time. I'll try [rw]mem_max, but when I tweaked the skb_alloc(?)
call in af_unix.o, the write() still gobbled as much as it could.
zw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:16 EST