lkml.org 
[lkml]   [2005]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/8] Cleanup kmem_cache_create()
Pekka J Enberg wrote:
> On Mon, 7 Nov 2005, Matthew Dobson wrote:
>
>>@@ -1652,9 +1649,9 @@ kmem_cache_t *kmem_cache_create(const ch
>> * gfp() funcs are more friendly towards high-order requests,
>> * this should be changed.
>> */
>>- do {
>>- unsigned int break_flag = 0;
>>-cal_wastage:
>>+ unsigned int break_flag = 0;
>>+
>>+ for ( ; ; cachep->gfporder++) {
>> cache_estimate(cachep->gfporder, size, align, flags,
>> &left_over, &cachep->num);
>> if (break_flag)
>>@@ -1662,13 +1659,13 @@ cal_wastage:
>> if (cachep->gfporder >= MAX_GFP_ORDER)
>> break;
>> if (!cachep->num)
>>- goto next;
>>- if (flags & CFLGS_OFF_SLAB &&
>>- cachep->num > offslab_limit) {
>>+ continue;
>>+ if ((flags & CFLGS_OFF_SLAB) &&
>>+ (cachep->num > offslab_limit)) {
>> /* This num of objs will cause problems. */
>>- cachep->gfporder--;
>>+ cachep->gfporder -= 2;
>
>
> This is not an improvement IMHO. The use of for construct is non-intuitive
> and neither is the above. A suggested cleanup is to keep the loop as is but
> extract it to a function of its own.
>
> Pekka

To me the for loop is more readable and intuitive, but that is definitely a
matter of opinion. Moving the code to it's own helper function is a better
idea than leaving it alone, or changing to a for loop, though. Will resend
later today.

Thanks!

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

\
 
 \ /
  Last update: 2005-11-08 19:57    [W:0.243 / U:1.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site