>It reflects the fact that the page lock can be held for a variety of >reasons, some of which require you to kick the filesystem and some which >don't.
So then what I don't understand is why you would make a call that tells you someone is trying to hold the page lock? Why not a call that tells you something meaningful like, "someone is trying to read this page"? Or "someone is waiting for this page to get clean?" >I introduced the sync_page() call in 2.4.x partly in order to get rid of >all those pathetic hard-coded calls to "run_task_queue(&tq_disk)" That was pathetic all right, and sync_page() would be a clear improvement if it just replaced those modularity-busting I/O scheduling calls. But did it? Were there run_task_queue's every time the kernel waited for page status to change? I thought they were in more eclectic places. >the NFS client itself had to defer actually >putting reads on the wire until someone requested the lock But really, you mean the client had to defer putting reads on the wire until someone was ready to use the data. That suggests a call to ->sync_page in file read or page fault code rather than deep in page management. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
