On Mon, Jan 13, 2014 at 11:38:44PM +0100, Jan Kara wrote: > On Mon 13-01-14 22:26:45, Mel Gorman wrote: > > The flipside is also meant to hold true. If you know data will be needed > > in the near future then posix_fadvise(POSIX_FADV_WILLNEED). Glancing at > > the implementation it does a forced read-ahead on the range of pages of > > interest. It doesn't look like it would block. > That's not quite true. POSIX_FADV_WILLNEED still needs to map logical > file offsets to physical disk blocks and create IO requests. This happens > synchronously. So if your disk is congested and relevant metadata is out of > cache, or we simply run out of free IO requests, POSIX_FADV_WILLNEED can > block for a significant amount of time. >
Umm, yes, you're right. It also potentially stalls allocating the pages up front even though it will only try and direct reclaim pages once. That can stall in some circumstances, particularly if there are a number of processes trying to reclaim memory. That kinda sucks though. One point of discussion would be to check if this is an interface that can be used and if so, is it required to never block and if so is there something we can do about it -- queue the IO asynchronously if you can but if the kernel would block then do not bother. That does mean that fadvise is not guaranteeing that the pages will be resident in the future but it was not the intent of the interface anyway. -- Mel Gorman SUSE Labs -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers