I was assuming it was a vm problem so I wasn't even thinking at the
other changes, but now thinking twice yes, the fact we block dropping
all the cache at the blkdev close could be the culprit. OTOH we were
just invalidating all the buffers cache also previously at the last
blkdev close, so it's not so obvious that it is the problem yet (but the
vmstat trace from Duncan also shows an immediate drop in pagecache
converted in free memory, so it could really be the close of the blkdev
given that xine isn't going to delete any dozen mbyte large file and
that probably doesn't allocate and deallocate some dozen mbyte of memory
in less than one second).
> If it does, then I suspect we should really look into making the raw
> device close just leave the device descriptor around at least for a
> while. Al?
In this case it sounds more like xine shouldn't close the device while
changing file (also with 2.4.9 the buffercache was dropped anyways), but
also allowing the cache to be persistent would make sense. I liked
trusting in the check-media-change logic for devices that are reliable
(for the others we must of course keep to invalidate the cache). I think
we should only make the bdev and bd_inode persistent, and have
check-media-change that tells us at open(2) time if the cache have to be
dropped or if we can trust the "media change" detection of the device
and avoid to drop it. Of course the cache will be reclaimed by the vm
over the time, I'm unsure if it worth to allow the garbage collection of
the bdev and of the bd_inode.
Anyways those changes aren't required for having a functional system so
maybe we can postpone this to 2.5 and instead fix xine not to close the
device (or to keep a dummy additional reference on the device for its
runtime).
Andrea
-
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/