Thread (5 messages) 5 messages, 3 authors, 2020-02-13

Re: [PATCH v8 07/11] proc: flush task dcache entries from all procfs instances

From: Al Viro <viro@zeniv.linux.org.uk>
Date: 2020-02-13 22:24:03
Also in: linux-api, linux-fsdevel, lkml

Possibly related (same subject, not in this thread)

On Thu, Feb 13, 2020 at 01:30:11PM -0800, Linus Torvalds wrote:
On Wed, Feb 12, 2020 at 9:55 PM Al Viro [off-list ref] wrote:
quoted
What I don't understand is the insistence on getting those dentries
via dcache lookups.
I don't think that's an "insistence", it's more of a "historical
behavior" together with "several changes over the years to deal with
dentry-level cleanups and updates".
quoted
_IF_ we are willing to live with cacheline
contention (on ->d_lock of root dentry, if nothing else), why not
do the following:
        * put all dentries of such directories ([0-9]* and [0-9]*/task/*)
into a list anchored in task_struct; have non-counting reference to
task_struct stored in them (might simplify part of get_proc_task() users,
Hmm.

Right now I don't think we actually create any dentries at all for the
short-lived process case.

Wouldn't your suggestion make fork/exit rather worse?

Or would you create the dentries dynamically still at lookup time, and
then attach them to the process at that point?

What list would you use for the dentry chaining? Would you play games
with the dentry hashing, and "hash" them off the process, and never
hit in the lookup cache?
I'd been thinking of ->d_fsdata pointing to a structure with list_head
and a (non-counting) task_struct pointer for those guys.  Allocated
on lookup, of course (as well as readdir ;-/) and put on the list
at the same time.

IOW, for short-lived process we simply have an empty (h)list anchored
in task_struct and that's it.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help