lkml.org 
[lkml]   [2014]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 03/10] slab: move up code to get kmem_cache_node in free_block()
(Oops, previous e-mail was sent halfway through composition in error.)

> I'm not sure it's even correct since
> you're now clearing after doing recheck_pfmemalloc_active().

I thought this through before rearranging the code.
recheck_pfmemalloc_active() checks global lists, but __ac_get_obj()
is doing clear_obj_pfmemalloc on a local variable. So it
can't affect recheck_pfmemalloc_active().

> A function called clear_obj_pfmemalloc() doesn't indicate it's returning
> anything, I think the vast majority of people would believe that it
> returns void just as it does.

Perhaps the name needs to be modified, but it's still pretty clear.
It just clears the bit in its argument and returns it, as opposed to
operating in-place.

In particular, when reading the code that calls it, there is obviously
a return value. What could it possibly be?

> There's no complier generated code optimization with this patch

On that subject, you're absolutely correct:
text data bss dec hex filename
10635 939 4 11578 2d3a mm/slab.o.before
10635 939 4 11578 2d3a mm/slab.o.after

If I don't have CONFIG_CC_OPTIMIZE_FOR_SIZE=y, the padding NOPs after
unconditional jumps get aligned a little differently and it actually
gets bigger.

text data bss dec hex filename
12958 1079 4 14041 36d9 mm/slab.o.before
12990 1079 4 14073 36f9 mm/slab.o.after

__ac_get_obj actually spills one fewer register in this case, and
the code paths seem a little cleaner, but I haven't gone through
it completely.


\
 
 \ /
  Last update: 2014-05-08 04:21    [W:0.104 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site