Re: buffer-cache builds up with invalidate=1 too

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26 October 2017 at 19:06, Jens Axboe <axboe@xxxxxxxxx> wrote:
> On 10/25/2017 10:32 PM, Jens Axboe wrote:
>> On 10/24/2017 08:10 AM, Paolo Valente wrote:
>>>
>>>> Il giorno 24 ott 2017, alle ore 08:28, Sitsofe Wheeler <sitsofe@xxxxxxxxx> ha scritto:
>>>>
>>>> Hi,
>>>>
>>>> If memory serves it's actually slightly more complicated. If you are
>>>> using loops=<number> then I *think* (you'll have to check) you will
>>>> find that invalidation happens once per each loop start. However when
>>>> you use time_based to do the repetition there is essentially only one
>>>> "loop" (even though the job goes on forever) so loop actions only
>>>> happen right at the start of the job with that option (that's why I
>>>> put the scare quotes around "beginning" ;-).
>>>>
>>>
>>> Thanks for this additional, useful piece of information.  Actually,
>>> this further, possibly different caching behavior makes me think that
>>> some extra comment in the manpage might be helpful.
>>
>> Would probably make sense to change 'invalidate' to be a range of
>> possible values:
>>
>> 0     As it is now, never invalidate
>> 1     As it is now, invalidate initially
>> once  Same as '1', invalidate initially / once
>> open  New value, invalidate on every open
>> close New value, invalidate on close
>>
>> as I can definitely see reasons why you would want to invalidate every
>> time you open the file.
>>
>> To do that, the 'invalidate' option should be changed from a
>> FIO_OPT_BOOL to a FIO_OPT_STR, and the above possible values should be
>> added as posval[] for that option.
>>
>> Compliment that with the an enum of ranges for the ovals:
>>
>> enum {
>>       FIO_FILE_INVALIDATE_OFF = 0,
>>       FIO_FILE_INVALIDATE_ONCE,
>>       FIO_FILE_INVALIDATE_OPEN,
>>       FIO_FILE_INVALIDATE_CLOSE
>> };
>>
>> Hope this makes sense, should be trivial to add as most of the work is
>> already documented in this email :-). The remaining bits is just calling
>> file_invalidate_cache() in the proper locations,
>> td_io_{open,close}_file() would be prime candidates.
>
> On a plane, so decided to take a look at this. Looking at how it's
> implemented, fio actually does do cache invalidation at open time,
> if you look at td_io_open_file(). I traced it, and it's invoked just
> fine by default, and if you use loops=X (with X > 1).

I was going to say - when I did the "windowsaio invalidate" I noticed
invalidation seemed linked to open.

> For time_based, we don't open and close the file, so we don't trigger
> that at all. We just loop/reset the offsets. Something like the below
> should do the trick.

Unfortunately I don't think it's easy to do effective invalidation
with open file handles on Windows so I think windowaio will have to
stay as is when using time_based. Is it OK that we don't change that
ioengine for now?

-- 
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe fio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux SCSI]     [Linux IDE]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux