On Thu, Sep 02, 2021 at 08:47:42AM -0700, Linus Torvalds wrote: > On Tue, Aug 31, 2021 at 2:18 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > As for new features: we now batch inode inactivations in percpu > > background threads, which sharply decreases frontend thread wait time > > when performing file deletions and should improve overall directory tree > > deletion times. > > So no complaints on this one, but I do have a reaction: we have a lot > of these random CPU hotplug events, and XFS now added another one. > > I don't see that as a problem, but just the _randomness_ of these > callbacks makes me go "hmm". And that "enum cpuhp_state" thing isn't > exactly a thing of beauty, and just makes me think there's something > nasty going on. > > For the new xfs usage, I really get the feeling that it's not that XFS > actually cares about the CPU states, but that this is literally tied > to just having percpu state allocated and active, and that maybe it > would be sensible to have something more specific to that kind of use. Correct -- we don't really care about cpu state at all; all xfs needs is to push batched work items on a per-cpu list to another cpu when a cpu goes offline. I didn't see anything that looked like it handled that kind of thing, so ... cpuhp_state it was. :/ > We have other things that are very similar in nature - like the page > allocator percpu caches etc, which for very similar reasons want cpu > dead/online notification. > > I'm only throwing this out as a reaction to this - I'm not sure > another interface would be good or worthwhile, but that "enum > cpuhp_state" is ugly enough that I thought I'd rope in Thomas for CPU > hotplug, and the percpu memory allocation people for comments. > > IOW, just _maybe_ we would want to have some kind of callback model > for "percpu_alloc()" and it being explicitly about allocations > becoming available or going away, rather than about CPU state. > > Comments? Seems like a good fit for us, though I'll let Dave Chinner chime in since he's the one with more per-cpu list patches coming up. > > Lastly, with this release, two new features have graduated to supported > > status: inode btree counters (for faster mounts), and support for dates > > beyond Y2038. > > Oh, I had thought Y2038 was already a non-issue for xfs. Silly me. It's been a new feature in upstream for a year now. We're merely taking down the scary warnings that using this new code might result in a subspace vortex opening in the skies or that all trains bound for Moynihan end up on track 19 or wherever. ;) --D > Linus
