2005-11-10 23:53:46

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 0/9] Cleanup mm/slab.c v2

Second take at cleaning up mm/slab.c. Patch series has picked up 2 new
patches and dropped one old one. The 2 new patches create new helper
functions, and I've dropped the patch to inline 3 functions after it was
deemed unecessary.

Appologies for the delay in getting version 2 out. /me is easily
distracted by shiny things.

-Matt


2005-11-10 23:56:47

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 1/9] CodingStyle-ify mm/slab.c

mm/slab.c is MESSY. Tabs where there should be spaces, spaces where there
should be tabs. Long lines, bad formatting, spelling errors, etc.
Everything you'd expect from such an oft-patched file. Let's start with
CodingStyle fixes.

Oh, and since I forgot to mention it in the 0/9 email, all these patches
are against 2.6.14.

-Matt


Attachments:
CodingStyle-slab_c.patch (81.96 kB)

2005-11-10 23:58:58

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 2/9] Use 'nid'

Rather than various and sundry names for a node's number, let's use 'nid'.

-Matt


Attachments:
use_nid.patch (22.76 kB)

2005-11-10 23:59:54

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 3/9] Fix alloc_percpu's args

alloc_percpu takes an 'align' argument that is completely ignored. Remove it.

-Matt


Attachments:
alloc_percpu.patch (3.14 kB)

2005-11-11 00:01:39

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 4/9] Create helper for /proc/slabinfo

Most of the s_start() function body is just printing out a header for
/proc/slabinfo. Move it to its own function.

-Matt


Attachments:
print_slabinfo_header.patch (2.52 kB)

2005-11-11 00:03:24

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 5/9] Create helper for kmem_cache_create()

There's a loop in kmem_cache_create() where we try to determine the best
page order for a slab. It's a big, ugly loop, so let's move it to its own
function: calculate_slab_order().

-Matt


Attachments:
calculate_slab_order.patch (3.49 kB)

2005-11-11 00:04:38

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 6/9] Cleanup kmem_cache_create()

kmem_cache_create() is a pretty big function, so we'll devote one whole
patch just to cleaning it up.

-Matt


Attachments:
kmem_cache_create.patch (4.59 kB)

2005-11-11 00:05:25

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 7/9] Cleanup cache_reap()

cache_reap() could also use a little love. Here's a patch to clean it up.

-Matt


Attachments:
cache_reap.patch (2.62 kB)

2005-11-11 00:06:34

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 8/9] Cleanup slabinfo_write()

Shuffle a little code around in slabinfo_write(), both for efficiency and
readability.

-Matt


Attachments:
slabinfo_write.patch (1.44 kB)

2005-11-11 00:07:29

by Matthew Dobson

[permalink] [raw]
Subject: [PATCH 9/9] Cleanup a loop in set_slab_attr()

Last, but not least, fix a loop in set_slab_attr() to match the rest of the
functionally similar loops in mm/slab.c.

-Matt


Attachments:
set_slab_attr.patch (731.00 B)

2005-11-11 07:29:58

by Pekka Enberg

[permalink] [raw]
Subject: Re: [PATCH 0/9] Cleanup mm/slab.c v2

On Thu, 10 Nov 2005, Matthew Dobson wrote:
> Second take at cleaning up mm/slab.c. Patch series has picked up 2 new
> patches and dropped one old one. The 2 new patches create new helper
> functions, and I've dropped the patch to inline 3 functions after it was
> deemed unecessary.

Looks good to me. Thanks Matthew!

Pekka

2005-11-11 08:10:46

by Ingo Oeser

[permalink] [raw]
Subject: Re: [PATCH 6/9] Cleanup kmem_cache_create()

On Friday 11 November 2005 01:04, Matthew Dobson wrote:
> - if (size < 4096 || fls(size - 1) == fls(size - 1 + 3 * BYTES_PER_WORD))
> + if (size < RED_ZONE_LIMIT ||
> + fls(size - 1) == fls(size - 1 + 3 * BYTES_PER_WORD))
> flags |= SLAB_RED_ZONE|SLAB_STORE_USER;

I would suggest sth. like

if (size < RED_TONE_LIMIT
|| fls(size - 1) = fls(size - 1 + 3 * BYTES_PER_WORD))
flags |= SLAB_RED_ZONE | SLAB_STORE_USER


Reason: A binary operator in front is a huge hint
that this is a continued line.

Just compare when you go to a store next time.

1
+ 2
- 3
* 4

is much more readable then

1 +
2 -
3 *
4

right?


Regards

Ingo Oeser



Attachments:
(No filename) (656.00 B)
(No filename) (189.00 B)
Download all attachments

2005-11-11 18:28:57

by Matthew Dobson

[permalink] [raw]
Subject: Re: [PATCH 6/9] Cleanup kmem_cache_create()

Ingo Oeser wrote:
> On Friday 11 November 2005 01:04, Matthew Dobson wrote:
>
>>- if (size < 4096 || fls(size - 1) == fls(size - 1 + 3 * BYTES_PER_WORD))
>>+ if (size < RED_ZONE_LIMIT ||
>>+ fls(size - 1) == fls(size - 1 + 3 * BYTES_PER_WORD))
>> flags |= SLAB_RED_ZONE|SLAB_STORE_USER;
>
>
> I would suggest sth. like
>
> if (size < RED_TONE_LIMIT
> || fls(size - 1) = fls(size - 1 + 3 * BYTES_PER_WORD))
> flags |= SLAB_RED_ZONE | SLAB_STORE_USER
>
>
> Reason: A binary operator in front is a huge hint
> that this is a continued line.
>
> Just compare when you go to a store next time.
>
> 1
> + 2
> - 3
> * 4
>
> is much more readable then
>
> 1 +
> 2 -
> 3 *
> 4
>
> right?
>
>
> Regards
>
> Ingo Oeser

You make a very good point. It's not the way that I'm used to writing
multi-line ifs, but it is a bit more readable. However, since the rest of
the multi-line ifs in the file have the binary operator at the end of the
first line, I'm inclined to leave it the way it is for consistency. If
anyone really feels strongly, I could come up with a patch for the whole
file...?

Thanks for the feedback!

-Matt

2005-11-16 18:39:42

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 2/9] Use 'nid'

On Thu 10-11-05 15:58:53, Matthew Dobson wrote:
> Rather than various and sundry names for a node's number, let's use 'nid'.

I'd say nodeid is better name... and please inline patches.
Pavel

--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms