On Tue, Feb 20, 2018 at 2:43 PM, Jan Kara <jack@xxxxxxx> wrote: > On Mon 19-02-18 21:07:28, Amir Goldstein wrote: [...] >> >> I just feel sorry about passing an opportunity to improve functionality. >> The fact that fanotify does not have a way for defining the events queue >> size is a deficiency IMO, one which I had to work around in the past. >> I find that assigning group to memgc and configure memcg to desired >> memory limit and getting Q_OVERFLOW on failure to allocate event >> is going to be a proper way of addressing this deficiency. > > So if you don't pass FAN_Q_UNLIMITED, you will get queue with a fixed size > and will get Q_OVERFLOW if that is exceeded. So is your concern that you'd > like some other fixed limit? Larger one or smaller one and for what > reason? > My use case was that with the default queue size, I would get Q_OVERFLOW on bursty fs workloads, but using FAN_Q_UNLIMITED and allowing to consume entire system memory with events was not a desired alternative. The actual queue size was not important, only allowing admin to tune the system to bursty workloads without overflowing the event queue. Something like FAN_Q_BESTEFFORT (i.e. Q_OVERFLOW on ENOMEM) + allowing to restrict event allocation to memcg, would allow admin to tune the system to bursty workloads. >> But if you don't think we should bind these 2 things together, >> I'll let Shakeel decide if he want to pursue the Q_OVERFLOW change >> or not. > > So if there is still some uncovered use case for finer tuning of event > queue length than setting or not setting FAN_Q_UNLIMITED (+ possibly > putting the task to memcg to limit memory usage), we can talk about how to > address that but at this point I don't see a strong reason to bind this to > whether / how events are accounted to memcg... Agreed. > > And we still need to make sure we properly do ENOMEM -> Q_OVERFLOW > translation and use GFP_NOFAIL for FAN_Q_UNLIMITED groups before merging Good. it wasn't clear to me from your summary if were going to require ENOEM -> Q_OVERFLOW before merging this work. If you put it this way, I think it makes sense to let user to choose between GFP_NOFAIL and Q_OVERFLOW behavior when queue is not limited, for example by using new fanotify_init flag FAN_Q_BESTEFFORT (or better name), but I have no problem with postponing that for later. Thanks, Amir. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
