Re: [PATCH v8 01/11] timekeeping: move multigrain timestamp floor handling into timekeeper

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

 



On Tue, 2024-10-01 at 14:45 +0200, Thomas Gleixner wrote:
> On Tue, Oct 01 2024 at 05:45, Jeff Layton wrote:
> > On Mon, 2024-09-30 at 23:35 +0200, Thomas Gleixner wrote:
> > > > I certainly wouldn't rule out a workqueue job calling that function,
> > > > but this is something we do while dirtying an inode, and that's not
> > > > typically done in interrupt context.
> > > 
> > > The reason I'm asking is that if it's always syscall context,
> > > i.e. write() or io_uring()/RPC request etc., then you can avoid the
> > > whole global floor value dance and make it strictly per thread, which
> > > simplifies the exercise significantly.
> > > 
> > 
> > I'm not sure I follow what you're proposing here.
> > 
> > Consider two threads doing writes serially to different files. IOW, the
> > second thread enters the write() syscall after the first thread returns
> > from its write(). In that situation, the second timestamp mustn't
> > appear to be earlier than the first (assuming no backward clock jump,
> > of course).
> > 
> > How would we ensure that with only per-thread structures?
> 
> Bah. Right. Ignore my sleep deprived rambling.

No worries. My one big takeaway from working on all of this is that
anything dealing with clocks and time is just difficult to
conceptualize.

Could I trouble you for an Acked-by on this patch? I think this series
should probably go in via Christian's tree, but I don't think he wants
to merge it without an explicit ack from the timekeeping maintainers.

Thanks again for the review!
-- 
Jeff Layton <jlayton@xxxxxxxxxx>





[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux