Messages in this thread | | | Date | Mon, 6 Jun 2005 21:30:20 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH] shmem: restore superblock info |
| |
On Mon, 6 Jun 2005, Brent Casavant wrote: > On Mon, 6 Jun 2005, Hugh Dickins wrote: > > > @@ -1607,15 +1582,17 @@ static int shmem_statfs(struct super_blo > > - if (sbinfo) { > > - spin_lock(&sbinfo->stat_lock); > > + spin_lock(&sbinfo->stat_lock); ... > > This is the only change I'm at all concerned about.
Thanks for noticing, I hadn't really considered that.
> I'm not sure how frequent statfs operations occur in practice (I suspect > infrequently),
Infrequently, yes. I think infrequently to the point of never in the case that concerns you: correct if I'm wrong, someone, but I think there's actually no handle by which user can statfs shm's internal mount.
> however simply changing the existing code from "if (sbinfo)" > to "if (sbinfo->max_blocks || sbinfo->max_inodes)" would be an appropriate > remedy if there is a real problem.
Hadn't thought of that, yes, can do if there's a real problem.
> That said, I'm not all that concerned about it, as my fuzzy memory > indicates it was the lock/unlock around the statistics updates which > caused the primary lock contention.
That's right, and certainly this shmem_statfs locking change didn't show up when you retested for me (thank you!) all those months ago.
Hugh - 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/
| |