lkml.org 
[lkml]   [2008]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [rfc] x86: optimise page fault path a little


On Thu, 13 Nov 2008, Nick Piggin wrote:
>
> It's only about 1.1% on the profile of the workload I'm looking at, so my
> improvement is pretty close to in the noise, but I wonder if micro
> optimisations like the following would be welcome?

I think splitting it up is good, but I hate how your split-up ends up also
splitting the locking (ie now you do a "down_read()" and "up_read()" in
different functions).

I also think that to some degree you made it less readable, particularly
this area:

+ if (write) {
+ if (unlikely(!(vma->vm_flags & VM_WRITE))) {
+ bad_area_accerr(regs, error_code, address);
+ return;
+ }
+ } else if (unlikely(error_code & PF_PROT)) {
+ bad_area_accerr(regs, error_code, address);
+ return;
+ } else if (unlikely(!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE)))) {
+ bad_area_accerr(regs, error_code, address);
+ return;

makes me go "whaa?" and I wonder if it wouldn't be nicer to have one
complex conditional hidden in an inline function, and then just have

if (unlikely(access_error(write, error_code, vma))) {
bad_area_access_error(regs, error_code, address);
return;
}

where the point is that we don't want to duplicate the error case three
times, and that "accerr" is bad naming.

IOW, I do think that the patch looks like a step in the right direction,
but cleanliness should be a primary concern.

Linus


\
 
 \ /
  Last update: 2008-11-13 17:05    [W:0.161 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site