On Fri, 18 Aug 2006, Andi Kleen wrote:
> Also I must say it's still not quite clear to me if it's better to place
> network packets on the node the device is connected to or on the
> node which contains the CPU who processes the packet data
> For RX this can be three different nodes in the worst
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Fri, 18 Aug 2006 11:29:14 +0200
> So ideal would be something dynamic to turn on/off io placement, maybe based
> on node_distance() again, with the threshold tweakable per architecture?
We have this ugly 'hashdist' thing, let's remove the __initdata tag
On Friday 18 August 2006 04:25, Christoph Lameter wrote:
> On Wed, 16 Aug 2006, Andi Kleen wrote:
> > That's not true on all NUMA systems (that they have a slow interconnect)
> > I think on x86-64 I would prefer if it was distributed evenly or maybe
> > even on the CPU who is finally going to proce
On Wed, 16 Aug 2006, Andi Kleen wrote:
> That's not true on all NUMA systems (that they have a slow interconnect)
> I think on x86-64 I would prefer if it was distributed evenly or maybe even
> on the CPU who is finally going to process it.
>
> -Andi "not all NUMA is an Altix"
The Altix NUMA in
On Wed, 16 Aug 2006 09:48:08 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 16, 2006 at 09:35:46AM +0400, Evgeniy Polyakov wrote:
> > On Tue, Aug 15, 2006 at 10:21:22PM +0200, Arnd Bergmann ([EMAIL PROTECTED])
> > wrote:
> > > Am Monday 14 August 2006 13:04 schrieb Evgeniy Polya
On Wed, Aug 16, 2006 at 01:27:02PM +0200, Arnd Bergmann ([EMAIL PROTECTED])
wrote:
> On Wednesday 16 August 2006 11:00, Evgeniy Polyakov wrote:
> > There is drawback here - if data was allocated on CPU wheere NIC is
> > "closer" and then processed on different CPU it will cost more than
> > in ca
On Wednesday 16 August 2006 11:00, Evgeniy Polyakov wrote:
> There is drawback here - if data was allocated on CPU wheere NIC is
> "closer" and then processed on different CPU it will cost more than
> in case where buffer was allocated on CPU where it will be processed.
>
> But from other point o
On Wed, Aug 16, 2006 at 02:40:08AM -0700, David Miller wrote:
> From: Christoph Hellwig <[EMAIL PROTECTED]>
> Date: Wed, 16 Aug 2006 10:38:37 +0100
>
> > We could, but I'd rather waste 4 bytes in struct net_device than
> > having such ugly warts in common code.
>
> Why not instead have struct dev
On Wed, Aug 16, 2006 at 01:00:31PM +0400, Evgeniy Polyakov wrote:
> On Wed, Aug 16, 2006 at 09:48:08AM +0100, Christoph Hellwig ([EMAIL
> PROTECTED]) wrote:
> > > Doesn't alloc_pages() automatically switches to alloc_pages_node() or
> > > alloc_pages_current()?
> >
> > That's not what's wanted.
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Wed, 16 Aug 2006 10:38:37 +0100
> We could, but I'd rather waste 4 bytes in struct net_device than
> having such ugly warts in common code.
Why not instead have struct device store some default node value?
The node decision will be sub-optimal on
On Wed, Aug 16, 2006 at 01:32:02PM +0400, Evgeniy Polyakov wrote:
> On Wed, Aug 16, 2006 at 10:10:29AM +0100, Christoph Hellwig ([EMAIL
> PROTECTED]) wrote:
> > On Wed, Aug 16, 2006 at 02:05:03AM -0700, David Miller wrote:
> > > From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> > > Date: Wed, 16 Aug 20
On Wed, Aug 16, 2006 at 10:10:29AM +0100, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> On Wed, Aug 16, 2006 at 02:05:03AM -0700, David Miller wrote:
> > From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> > Date: Wed, 16 Aug 2006 13:00:31 +0400
> >
> > > So I would like to know how to determine which
On Wed, Aug 16, 2006 at 02:05:03AM -0700, David Miller wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Wed, 16 Aug 2006 13:00:31 +0400
>
> > So I would like to know how to determine which node should be used for
> > allocation. Changes of __get_user_pages() to alloc_pages_node() are
>
On Wed, Aug 16, 2006 at 09:48:08AM +0100, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> > Doesn't alloc_pages() automatically switches to alloc_pages_node() or
> > alloc_pages_current()?
>
> That's not what's wanted. If you have a slow interconnect you always want
> to allocate memory on the no
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 16 Aug 2006 13:00:31 +0400
> So I would like to know how to determine which node should be used for
> allocation. Changes of __get_user_pages() to alloc_pages_node() are
> trivial.
netdev_alloc_skb() knows the netdevice, and therefore you can
On Wed, Aug 16, 2006 at 09:35:46AM +0400, Evgeniy Polyakov wrote:
> On Tue, Aug 15, 2006 at 10:21:22PM +0200, Arnd Bergmann ([EMAIL PROTECTED])
> wrote:
> > Am Monday 14 August 2006 13:04 schrieb Evgeniy Polyakov:
> > > ?* full per CPU allocation and freeing (objects are never freed on
> > > ?
On Tue, Aug 15, 2006 at 10:52:37PM -0400, Bill Fink ([EMAIL PROTECTED]) wrote:
> > Let's main system works only with TCP for simplicity.
> > Let's maximum allowed memory is limited by 1mb (it is 768k on machine
> > with 1gb of ram).
>
> The maximum amount of memory available for TCP on a system wi
On Tue, 15 Aug 2006, Evgeniy Polyakov wrote:
> On Tue, Aug 15, 2006 at 03:49:28PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
>
> > It could if you can provide adequate detection of memory pressure and
> > fallback to a degraded mode within the same allocator/stack and can
> > guarantee l
On Tue, Aug 15, 2006 at 07:42:16PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> Right, however I just realised that most storage protocols (level 7)
> have their own ACK msgs and do not rely on TCP (level 4) ACKs like this.
>
> So I would like to come back on this, I do need a full data cha
On Tue, 2006-08-15 at 19:05 +0400, Evgeniy Polyakov wrote:
> > Not sure on the details; but you say: when we reach the threshold all
> > following packets will be dropped. So if you provide enough memory to
> > exceed the limit, you have some extra. If you then use that extra bit to
> > allow ACKs
On Tue, Aug 15, 2006 at 07:05:07PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> > > So network allocator reserves above megabyte and works with it in a
> > > smart way (without too much overhead).
> > > Then system goes into OOM and requires to swap a page, which
> > > notification was sen
On Tue, Aug 15, 2006 at 04:48:59PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> On Tue, 2006-08-15 at 18:15 +0400, Evgeniy Polyakov wrote:
>
> > Kevent network AIO is completely different from network tree allocator.
>
> How can that be? packets still need to be received, yes?
Kevent netw
On Tue, 2006-08-15 at 18:15 +0400, Evgeniy Polyakov wrote:
> Kevent network AIO is completely different from network tree allocator.
How can that be? packets still need to be received, yes?
> So network allocator reserves above megabyte and works with it in a
> smart way (without too much overhe
On Tue, Aug 15, 2006 at 03:49:28PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> On Tue, 2006-08-15 at 16:34 +0400, Evgeniy Polyakov wrote:
> > On Tue, Aug 15, 2006 at 02:03:25PM +0200, Peter Zijlstra ([EMAIL
> > PROTECTED]) wrote:
> > > On Tue, 2006-08-15 at 15:26 +0400, Evgeniy Polyakov wr
On Tue, 2006-08-15 at 16:34 +0400, Evgeniy Polyakov wrote:
> On Tue, Aug 15, 2006 at 02:03:25PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
> > On Tue, 2006-08-15 at 15:26 +0400, Evgeniy Polyakov wrote:
> > > On Tue, Aug 15, 2006 at 12:55:02PM +0200, Peter Zijlstra ([EMAIL
> > > PROTECTED]
On Tue, Aug 15, 2006 at 02:03:25PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> On Tue, 2006-08-15 at 15:26 +0400, Evgeniy Polyakov wrote:
> > On Tue, Aug 15, 2006 at 12:55:02PM +0200, Peter Zijlstra ([EMAIL
> > PROTECTED]) wrote:
> > > > Userspace can sak for next packet and pointer to the
On Tue, 2006-08-15 at 15:26 +0400, Evgeniy Polyakov wrote:
> On Tue, Aug 15, 2006 at 12:55:02PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
> > > Userspace can sak for next packet and pointer to the new location will
> > > be removed.
> >
> > /sak/ask/?
> >
> > I'm not understanding, if y
On Tue, Aug 15, 2006 at 12:55:02PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> > Userspace can sak for next packet and pointer to the new location will
> > be removed.
>
> /sak/ask/?
>
> I'm not understanding, if you have a page A with two packets, a and b;
> once you map that page into u
On Mon, 2006-08-14 at 16:35 +0400, Evgeniy Polyakov wrote:
> On Mon, Aug 14, 2006 at 02:25:13PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
> > On Mon, 2006-08-14 at 15:04 +0400, Evgeniy Polyakov wrote:
> >
> > > Defragmentation is a part of freeing algorithm and initial fragmentation
> >
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Tue, 15 Aug 2006 14:02:28 +0400
> I had a version with per-cpu data - it is not very convenient to use
> here with it's per_cpu_ptr dereferencings
It does eat lots of space though, even for non-present cpus, and for
local cpu case the access ma
On Tue, Aug 15, 2006 at 10:08:23AM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> > There will be heaps of cacheline pingpong accessing these arrays. I'd have
> > though that
> >
> > static struct whatever {
> > avl_t avl_node_id;
> > struc
On Tue, Aug 15, 2006 at 12:27:24AM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> On Mon, 14 Aug 2006 15:04:03 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> >
> > Design of allocator allows to map all node's pages into userspace thus
> > allows to have true zero-copy support for bot
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> There will be heaps of cacheline pingpong accessing these arrays. I'd have
> though that
>
> static struct whatever {
> avl_t avl_node_id;
> struct avl_node **avl_node_array;
> struct list_head *avl_container_array;
> struct a
On Mon, 14 Aug 2006 15:04:03 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> Design of allocator allows to map all node's pages into userspace thus
> allows to have true zero-copy support for both sending and receiving
> dataflows.
If the pages can be order-1 or higher then they'll need to
From: Rick Jones <[EMAIL PROTECTED]>
Date: Mon, 14 Aug 2006 10:42:55 -0700
> Now, PA-RISC CPUs have the ability to disable spaceid hashing, and it is
> entirely possible that the PA-RISC linux port does that, but I thought I
> would mention it as an example. I'm sure the "official" PA-RISC linu
On Mon, Aug 14, 2006 at 10:46:17AM -0700, Rick Jones ([EMAIL PROTECTED]) wrote:
> >Benchmarks with trivial epoll based web server showed noticeble (more
> >than 40%) imrovements of the request rates (1600-1800 requests per
> >second vs. more than 2300 ones). It can be described by more
> >cache-fri
Benchmarks with trivial epoll based web server showed noticeble (more
than 40%) imrovements of the request rates (1600-1800 requests per
second vs. more than 2300 ones). It can be described by more
cache-friendly freeing algorithm, by tighter objects packing and thus
reduced cache line ping-pongs,
Evgeniy Polyakov wrote:
On Mon, Aug 14, 2006 at 10:07:48PM +1000, Keith Owens (kaos@ocs.com.au) wrote:
Evgeniy Polyakov (on Mon, 14 Aug 2006 15:04:03 +0400) wrote:
Network tree allocator can be used to allocate memory for all network
operations from any context
...
Design of allocator all
On Mon, Aug 14, 2006 at 04:35:30PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> > I'm still not clear on how you want to do this, only the trivial case of
> > a sniffer was mentioned by you. To be able to do true zero-copy receive
> > each packet will have to have its own page(s). Simply b
On Mon, Aug 14, 2006 at 02:25:13PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> On Mon, 2006-08-14 at 15:04 +0400, Evgeniy Polyakov wrote:
>
> > Defragmentation is a part of freeing algorithm and initial fragmentation
> > avoidance is being done at allocation time by removing power-of-two
>
On Mon, 2006-08-14 at 15:04 +0400, Evgeniy Polyakov wrote:
> Defragmentation is a part of freeing algorithm and initial fragmentation
> avoidance is being done at allocation time by removing power-of-two
> allocations. Rate of fragmentation can be found in some userspace
> modlling tests being don
On Mon, Aug 14, 2006 at 10:07:48PM +1000, Keith Owens (kaos@ocs.com.au) wrote:
> Evgeniy Polyakov (on Mon, 14 Aug 2006 15:04:03 +0400) wrote:
> >Network tree allocator can be used to allocate memory for all network
> >operations from any context
> >...
> >Design of allocator allows to map all n
Evgeniy Polyakov (on Mon, 14 Aug 2006 15:04:03 +0400) wrote:
>Network tree allocator can be used to allocate memory for all network
>operations from any context
>...
>Design of allocator allows to map all node's pages into userspace thus
>allows to have true zero-copy support for both sending a
On Mon, Aug 14, 2006 at 01:40:21PM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
>
> > Design notes.
> > Original idea was to store meta information used for allocation in an
> > AVL tree [1], but since I found a way to use some "unused" fields in stru
Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
> Design notes.
> Original idea was to store meta information used for allocation in an
> AVL tree [1], but since I found a way to use some "unused" fields in struct
> page,
> tree is unused in the allocator.
But there seems to be still an AVL tree in
On Mon, Aug 14, 2006 at 04:22:06AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Mon, 14 Aug 2006 15:04:03 +0400
>
> > /* These elements must be at the end, see alloc_skb() for details. */
> > - unsigned inttruesize;
> > +
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Mon, 14 Aug 2006 15:04:03 +0400
> /* These elements must be at the end, see alloc_skb() for details. */
> - unsigned inttruesize;
> + unsigned inttruesize, __tsize;
There is no real need for new member.
> -
Hello.
Network tree allocator can be used to allocate memory for all network
operations from any context. Main designed features are:
* reduced fragmentation (self defragmentation)
* possibility to create zero-copy sending and receiving (ground work
for userspace netchannels and high-pe
48 matches
Mail list logo
