Re: NFS client latencies

From: Trond Myklebust (trond.myklebust_at_fys.uio.no)
Date: 03/31/05

  • Next message: Patrick Mochel: "Re: [linux-pm] Re: swsusp 'disk' fails in bk-current - intel_agp at fault?"
    To: Ingo Molnar <mingo@elte.hu>
    Date:	Thu, 31 Mar 2005 11:00:58 -0500
    
    

    to den 31.03.2005 Klokka 17:10 (+0200) skreiv Ingo Molnar:
    > * Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
    >
    > > > would it be safe to collect locked entries into a separate, local list,
    > > > so that the restart would only see newly added entries? Then once the
    > > > moving of all entries has been done, all the locked entries could be
    > > > added back to the commit_list via one list_add. (can anything happen to
    > > > those locked entries that would break this method?)
    > >
    > > You are not allowed to remove an entry from the list if it is locked
    > > by someone else. Locking grants temporary ownership of the entry.
    >
    > well, removing a neighboring entry will change the locked entry's link
    > fields (e.g. req->wb_list.prev), so this ownership cannot involve this
    > particular list, can it?

    The point is that you are taking something that was previously globally
    visible and owned by somebody else and making it globally invisible by
    placing it on a private list.
    I'm not sure whether or not that is going to cause bugs in the current
    code (it may actually be safe with the current code), but as far as
    clean ownership semantics go, it sucks.

    Cheers,
      Trond

    -- 
    Trond Myklebust <trond.myklebust@fys.uio.no>
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Patrick Mochel: "Re: [linux-pm] Re: swsusp 'disk' fails in bk-current - intel_agp at fault?"

    Relevant Pages

    • Re: NFS client latencies
      ... to den 31.03.2005 Klokka 16:54 skreiv Ingo Molnar: ... > necessarily safe and might be removed from the commit_list? ... > entry. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: RCU issue with SELinux (Re: SELINUX performance issues)
      ... to control the audit-log floods. ... This adverse effect is only that audit-logs are printed twice. ... if an entry with the same ssid/tsid/tclass as new ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: FS: hardlinks on directories
      ... Just adding one more entry ... > could/would break the entire structure. ... Or adding SQL injections to other applications... ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE
      ... places want to actually update just the dirty and accessed bits. ... we should be able to have a BUG() in "set_pte" if the entry ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [OT] 1500 days uptime.
      ... root server and a NIS server. ... If anyone is interested in the last entry, I'll see if I can dig itup from ... Lab tests show that use of micro$oft causes cancer in lab animals ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)