Re: [PATCH 1/1] network memory allocator.

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 avl_node *avl_root;
> 	struct avl_free_list *avl_free_list_head;
> 	spinlock_t avl_free_lock;
> } __cacheline_aligned_in_smp whatevers[NR_CPUS];
> 
> would be better.

Or even better per cpu data. New global/static NR_CPUS arrays should be really discouraged.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• Follow-Ups:
  • Re: [PATCH 1/1] network memory allocator.
    • From: Evgeniy Polyakov <[email protected]>

• References:
  • [PATCH 1/1] network memory allocator.
    • From: Evgeniy Polyakov <[email protected]>
  • Re: [PATCH 1/1] network memory allocator.
    • From: Andrew Morton <[email protected]>

• Prev by Date: Re: RFC - how to balance Dirty+Writeback in the face of slow writeback.
• Next by Date: Re: [RHEL5 PATCH 1/4] Provide fallback full 64-bit divide/modulus ops for gcc
• Previous by thread: Re: [PATCH 1/1] network memory allocator.
• Next by thread: Re: [PATCH 1/1] network memory allocator.
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]