[lkml]   [2000]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Updated Linux 2.4 Status/TODO List (from the ALS show)
> On Thu, 12 Oct 2000, David S. Miller wrote:
> >
> > page_table_lock is supposed to protect normal page table activity (like
> > what's done in page fault handler) from swapping out.
> > However, grabbing this lock in swap-out code is completely missing!
> >
> > Audrey, vmlist_access_{un,}lock == unlocking/locking page_table_lock.
> Yeah, it's an easy mistake to make.
> I've made it myself - grepping for page_table_lock and coming up empty in
> places where I expected it to be.
> In fact, if somebody sends me patches to remove the "vmlist_access_lock()"
> stuff completely, and replace them with explicit page_table_lock things,
> I'll apply it pretty much immediately. I don't like information hiding,
> and right now that's the only thing that the vmlist_access_lock() stuff is
> doing.


I came up with the vmlist_access_lock/vmlist_modify_lock names early in
2.3. The reasoning behind that was that in most places where the "vmlist
lock" was being taken was to protect the vmlist chain, vma_t fields or
mm_struct fields. The fact that implementation wise this lock could be
the same as page_table_lock was a good idea that you suggested.

Nevertheless, the name was chosen to indicate what type of things it was
guarding. For example, in the future, you might actually have a different
(possibly sleeping) lock to guard the vmachain etc, but still have a
spin lock for the page_table_lock (No, I don't want to be drawn into a
discussion of why this might be needed right now). Some of this is
mentioned in Documentation/vm/locking.

Just thought I would mention, in case you don't recollect some of this
history. Of course, I understand the "information hiding" part.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.088 / U:1.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site