lkml.org 
[lkml]   [2009]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [git pull] cpus4096 tree, part 3

    * Andrew Morton <akpm@linux-foundation.org> wrote:

    > but why did the current code pass testing at all??

    i queued it up a week ago and beyond a same-day breakage i reported to
    Nick (and which he fixed) this commit was problem-free and passed all
    testing here.

    Does it cause problems for you? If yes then please describe the kind of
    problems.

    Note: i see that -mm modifies a few other details of the x86 pagefault
    handling path (there a pagefault-retry patch in there) - so there might be
    contextual interactions there. But this particular cleanup/improvement
    from Nick is working fine on a wide range of systems here.

    Btw., regarding pagefault retry. The bits that are in -mm currently i
    find a bit ugly:

    > +++ a/arch/x86/mm/fault.c
    > @@ -799,7 +799,7 @@ void __kprobes do_page_fault(struct pt_r
    > struct vm_area_struct *vma;
    > int write;
    > int fault;
    > - unsigned int retry_flag = FAULT_FLAG_RETRY;
    > + int retry_flag = 1;
    >
    > tsk = current;
    > mm = tsk->mm;
    > @@ -951,6 +951,7 @@ good_area:
    > }
    >
    > write |= retry_flag;
    > +
    > /*
    > * If for any reason at all we couldn't handle the fault,
    > * make sure we exit gracefully rather than endlessly redo
    > @@ -969,8 +970,8 @@ good_area:
    > * be removed or changed after the retry.
    > */
    > if (fault & VM_FAULT_RETRY) {
    > - if (write & FAULT_FLAG_RETRY) {
    > - retry_flag &= ~FAULT_FLAG_RETRY;
    > + if (retry_flag) {
    > + retry_flag = 0;
    > goto retry;
    > }
    > BUG();

    as this complicates every architecture with a 'can the fault be retried'
    logic and open-coded retry loop.

    But that logic is rather repetitive and once an architecture filters out
    all its special in-kernel sources of faults and the hw quirks it has, the
    handling of pte faults is rather generic and largely offloaded into
    handle_pte_fault() already.

    So when this patch was submitted a few weeks ago i suggested that retry
    should be done purely in mm/memory.c instead, and the low level code
    should at most be refactored to suit this method, but not complicated any
    further.

    Any deep reasons for why such a more generic approach is not desirable?

    Ingo


    \
     
     \ /
      Last update: 2009-01-26 21:13    [W:0.025 / U:119.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site