> Date: Fri, 12 Aug 2016 14:26:34 +0200
> From: Claudio Jeker
>
> On Fri, Aug 12, 2016 at 04:38:45PM +1000, David Gwynne wrote:
> >
> > > On 1 Aug 2016, at 21:07, Simon Mages wrote:
> > >
> > > I sent this message to dlg@ directly to discuss my modification of his
> > > diff to make the
> > >
On Fri, Aug 12, 2016 at 04:38:45PM +1000, David Gwynne wrote:
>
> > On 1 Aug 2016, at 21:07, Simon Mages wrote:
> >
> > I sent this message to dlg@ directly to discuss my modification of his
> > diff to make the
> > bigger mbuf clusters work. i got no response so far, thats why i
> > decided to
buf clusters for their rx rings.
Anyway, shouldn't the diff be using ulmin()?
> dlg
>
> >
> > BR
> > Simon
> >
> > ### Original Mail:
> >
> > ------ Forwarded message ------
> > From: Simon Mages
> > Date: Fri, 22 Jul 2016 13
On 2016-06-23 05:42, Theo de Raadt wrote:
secondly, allocating more than 4g at a time to socket buffers is
generally a waste of memory.
and there is one further problem.
Eventually, this subsystem will starve the system. Other subsystems
which also need large amounts of memory, then have to s
nce measurement would also be interesting :)
dlg
>
> BR
> Simon
>
> ### Original Mail:
>
> -- Forwarded message --
> From: Simon Mages
> Date: Fri, 22 Jul 2016 13:24:24 +0200
> Subject: Re: [PATCH] let the mbufs use more then 4gb of memory
&g
--
From: Simon Mages
Date: Fri, 22 Jul 2016 13:24:24 +0200
Subject: Re: [PATCH] let the mbufs use more then 4gb of memory
To: David Gwynne
Hi,
I think i found the problem with your diff regarding the bigger mbuf clusters.
You choose a buffer size based on space and resid, but what happens
On Thu, Jun 23, 2016 at 02:41:53PM +0200, Mark Kettenis wrote:
> > Date: Thu, 23 Jun 2016 13:09:28 +0200
> > From: Alexander Bluhm
> >
> > On Wed, Jun 22, 2016 at 10:54:27PM +1000, David Gwynne wrote:
> > > secondly, allocating more than 4g at a time to socket buffers is
> > > generally a waste o
On Thursday 23 June 2016 14:41:53, Mark Kettenis wrote:
> We really don't want to implement bounce-buffers. Adding IOMMU
> support is probably a better approach as it also brings some
> security benefits. Not all amd64 hardware supports an IOMMU. And
> hardware that does support it doesn't alway
Mark Kettenis [mark.kette...@xs4all.nl] wrote:
>
> We really don't want to implement bounce-buffers. Adding IOMMU
> support is probably a better approach as it also brings some security
> benefits. Not all amd64 hardware supports an IOMMU. And hardware
> that does support it doesn't always have
> Date: Thu, 23 Jun 2016 13:09:28 +0200
> From: Alexander Bluhm
>
> On Wed, Jun 22, 2016 at 10:54:27PM +1000, David Gwynne wrote:
> > secondly, allocating more than 4g at a time to socket buffers is
> > generally a waste of memory. in practice you should scale the amount
> > of memory available t
On Wed, Jun 22, 2016 at 10:54:27PM +1000, David Gwynne wrote:
> secondly, allocating more than 4g at a time to socket buffers is
> generally a waste of memory. in practice you should scale the amount
> of memory available to sockets according to the size of the tcp
> windows you need to saturate th
> secondly, allocating more than 4g at a time to socket buffers is
> generally a waste of memory.
and there is one further problem.
Eventually, this subsystem will starve the system. Other subsystems
which also need large amounts of memory, then have to scramble. There
have to be backpressure m
On Wed, Jun 22, 2016 at 01:58:25PM +0200, Simon Mages wrote:
> On a System where you use the maximum socketbuffer size of 256kbyte you
> can run out of memory after less then 9k open sockets.
>
> My patch adds a new uvm_constraint for the mbufs with a bigger memory area.
> I choose this area after
On Wed, Jun 22, 2016 at 01:58:25PM +0200, Simon Mages wrote:
> On a System where you use the maximum socketbuffer size of 256kbyte you
> can run out of memory after less then 9k open sockets.
>
> My patch adds a new uvm_constraint for the mbufs with a bigger memory area.
> I choose this area after
On a System where you use the maximum socketbuffer size of 256kbyte you
can run out of memory after less then 9k open sockets.
My patch adds a new uvm_constraint for the mbufs with a bigger memory area.
I choose this area after reading the comments in sys/arch/amd64/include/pmap.h.
This patch furt
15 matches
Mail list logo
