Hi Hin-Tak, On Wed, 2014-04-09 at 15:28 +0100, Hin-Tak Leung wrote: > > There are different ways of dividing a series of patches. One can go about > it purpose-based; but then, API-based (a patch for every usage instance of one > function, one type of changes) is valid too, and sometimes cleaner to review. > > I have thought of one reason why one might want to split the current patch > up: for cherry-picking/back-porting the long name fix to much older kernels which > do not have the relatively new attribute stuff. But then, it is simple enough > that it isn't too painful to backport by hand, if anybody really want it. > > Anyway, there are more patches to come, I am just not insisting on a declaring > a plan for an explicit series. Anybody who wants to put his name > down on further corrections is free to have a go. > Yes, it is possible to have different splitting fixes between patches. I simply think that if you mix the fix for file names and partial fix in hfsplus_listxattr() in one patch then it needs to use patchset scheme. Because rest fixes for xattr names should be in other patches of the patchset. Otherwise, it needs to have one patch for file names fix and other patches for xattr names. Of course, it's only my opinion and I don't insist on this way. But it's right way for me. > >Otherwise, you can use any splitting of fixes between patches. In my > >last e-mail I suggested to use kmem cache approach for xattr names > >instead of kmalloc only. > > I looked up what kmem cache does - I am not entirely convinced it would be > faster/better. Remember we are talking about converting > stack allocations which last the duration of 1 routine (the listxattr is longer, > but all the others seem to be quite short), to dynamic allocations. > They are fairly short-duration. kmem cache is more useful with things > like inodes and dentry, which are relatively long lasting uniform sizes, > but comes and goes. It could even be the case that kmem cache is > *slower* in this case because of its small over-heads for exremely temporary > allocations like these. We just don't know yet - or at least I don't know it yet :-). > But what difference between inode buffers and xattr name buffers? Inode buffer has fixed size and xatr buffer has fixed size. Inodes and xattr names comes and goes. Maybe, xattr name buffer has shorter lifetime. Efficiency is not only performance but good way of memory using. We know that xattr buffer has fixed size and it can be many simultaneous requests for such buffers creation. When we create kmem cache then we share our knowledge about fixed size nature of data with memory subsystem. Otherwise, memory subsystem will work in more sophisticated way. Maybe, I am wrong or misunderstand something here. But I see similarity between inode buffers and xattr name buffers. Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
