Messages in this thread | | | Date | Thu, 13 Nov 2008 08:00:08 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [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
| |