Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[Patch\]\s+Cacheline\s+align\s+xlog_t\s*$/: 24 ]

Total 24 documents matching your query.

1. [Patch] Cacheline align xlog_t (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Wed, 2 Apr 2008 09:15:52 +1000
Reorganise xlog_t for better cacheline isolation of contention To reduce contention on the log in large CPU count, separate out different parts of the xlog_t structure onto different cachelines. Move
/archives/xfs/2008-04/msg00006.html (14,439 bytes)

2. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Wed, 02 Apr 2008 16:35:40 +1000
Looks good - just one comment. David Chinner wrote: Reorganise xlog_t for better cacheline isolation of contention To reduce contention on the log in large CPU count, separate out different parts of
/archives/xfs/2008-04/msg00025.html (14,542 bytes)

3. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Wed, 2 Apr 2008 15:44:03 +1000
This just means that the start of the structure is cacheline aligned. I don't think the internal alignment commands force the entire structure to be cacheline aligned, merely pad the struture interna
/archives/xfs/2008-04/msg00026.html (9,390 bytes)

4. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: 02 Apr 2008 10:28:07 +0200
Isn't the structure dynamically allocated anyways? The full type alignment really only matters for statics/globals where the linker can handle it. For the dynamic allocation you would rather need to
/archives/xfs/2008-04/msg00038.html (9,153 bytes)

5. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Thu, 3 Apr 2008 08:23:47 +1000
Ah, right you are. My bad. Yup. Is there an allocator function gives us cacheline aligned allocation (apart from a slab initialised with SLAB_HWCACHE_ALIGN)? There isn't one, right? Cheers, Dave. --
/archives/xfs/2008-04/msg00042.html (9,738 bytes)

6. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Thu, 3 Apr 2008 08:46:08 +0200
__get_free_pages() @) [ok not serious] That too yes. You can always align yourself with kmalloc (or any other arbitary size allocator) with the standard technique: get L1_CACHE_BYTES-1 or possibly be
/archives/xfs/2008-04/msg00061.html (9,496 bytes)

7. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: Timothy Shimmin <tes@xxxxxxx>
Date: Fri, 04 Apr 2008 12:02:06 +1100
Andi Kleen wrote: On Thu, Apr 03, 2008 at 08:23:47AM +1000, David Chinner wrote: For the dynamic allocation you would rather need to make sure it starts at a cache line boundary explicitely because t
/archives/xfs/2008-04/msg00084.html (10,069 bytes)

8. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Fri, 4 Apr 2008 11:18:31 +1000
Great. I guess that means a wrapper function is in order. I'm not going to deal with this as part of this patch series, though. I'll just remove the superfluous notations. Patch below. Cheers, Dave.
/archives/xfs/2008-04/msg00085.html (17,590 bytes)

9. ure (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Wed, 2 Apr 2008 09:15:52 +1000
ves XFS specific ioctl interfaces and request codes for freeze feature. This patch has been supplied by David Chinner. Signed-off-by: Dave Chinner <dgc@xxxxxxx> Signed-off-by: Takashi Sato <t-
/archives/xfs/2008-04/msg00602.html (14,439 bytes)

10. eds to support sector size != 512 bytes (score: 1)
Author: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Wed, 02 Apr 2008 16:35:40 +1000
one - cleans up a lot of code. Looks good to me. David Chinner wrote: Remove the xlog_ticket allocator The ticket allocator is just a simple slab implementation internal to the log. It requires
/archives/xfs/2008-04/msg00621.html (14,542 bytes)

11. ytes (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Wed, 2 Apr 2008 15:44:03 +1000
091 assumes a direct I/O alignment of 512 bytes, a hold over from 2.4 kernels. On 2.6. kernels, direct I/O needs to be aligned to the sector size the filesystem was mkfs'd with. Teach 091 about
/archives/xfs/2008-04/msg00622.html (9,390 bytes)

12. eds to support sector size != 512 bytes (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: 02 Apr 2008 10:28:07 +0200
the core of the case-insensitive support - supporting and enforcing UTF-8 (Unicode) filenames. All filename and user-level extended attribute names are checked for UTF-8 compliance and the ha
/archives/xfs/2008-04/msg00634.html (9,153 bytes)

13. d timeout feature (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Thu, 3 Apr 2008 08:23:47 +1000
Chinner wrote: Exactly my timeout feature is only for an application, not for freeze_bdev(). I think it is needed for the situation we can't unfreeze from userspace. (e.g. Freezing the root fi
/archives/xfs/2008-04/msg00638.html (9,738 bytes)

14. case-insensitive match for dentry cache (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: Thu, 3 Apr 2008 08:46:08 +0200
onfusing with cip = "child inode" and ci_name = "case insensitive". i.e. same prefix, different meanings... if (!ci_name.name) return d_splice_alias(inode, dentry); This looks like it came from
/archives/xfs/2008-04/msg00657.html (9,496 bytes)

15. ive Language Support for Unicode in XFS (score: 1)
Author: Timothy Shimmin <tes@xxxxxxx>
Date: Fri, 04 Apr 2008 12:02:06 +1100
ndeen wrote: Jeremy Allison wrote: On Thu, Apr 03, 2008 at 01:14:50PM -0400, Christoph Hellwig wrote: Validating file names is not the filesystem job. In fact it's utterly stupid, a unix filen
/archives/xfs/2008-04/msg00680.html (10,069 bytes)

16. XFS (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Fri, 4 Apr 2008 11:18:31 +1000
hese options unconditionally - reject them later once we have all the info we need off disk (as has been previously suggested). May as well change these to the standard XFS function format....
/archives/xfs/2008-04/msg00681.html (17,590 bytes)

17. [Patch] Cacheline align xlog_t (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Wed, 2 Apr 2008 09:15:52 +1000
Reorganise xlog_t for better cacheline isolation of contention To reduce contention on the log in large CPU count, separate out different parts of the xlog_t structure onto different cachelines. Move
/archives/xfs/2008-04/msg01198.html (14,439 bytes)

18. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Wed, 02 Apr 2008 16:35:40 +1000
Looks good - just one comment. To reduce contention on the log in large CPU count, separate out different parts of the xlog_t structure onto different cachelines. Move each lock onto a different cach
/archives/xfs/2008-04/msg01217.html (15,836 bytes)

19. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Wed, 2 Apr 2008 15:44:03 +1000
This just means that the start of the structure is cacheline aligned. I don't think the internal alignment commands force the entire structure to be cacheline aligned, merely pad the struture interna
/archives/xfs/2008-04/msg01218.html (9,472 bytes)

20. Re: [Patch] Cacheline align xlog_t (score: 1)
Author: Andi Kleen <andi@xxxxxxxxxxxxxx>
Date: 02 Apr 2008 10:28:07 +0200
Isn't the structure dynamically allocated anyways? The full type alignment really only matters for statics/globals where the linker can handle it. For the dynamic allocation you would rather need to
/archives/xfs/2008-04/msg01230.html (9,279 bytes)


This search system is powered by Namazu