From: Oleg Nesterov <oleg@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Al Viro" <viro@zeniv.linux.org.uk>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@kernel.org>,
"Maciej Żenczykowski" <maze@google.com>
Subject: change filp_close() to use __fput_sync() ? (Was: [PATCH] task_work: remove fifo ordering guarantee)
Date: Mon, 31 Aug 2015 14:05:25 +0200 [thread overview]
Message-ID: <20150831120525.GA31015@redhat.com> (raw)
In-Reply-To: <1440856650.8932.144.camel@edumazet-glaptop2.roam.corp.google.com>
On 08/29, Eric Dumazet wrote:
>
> On Sat, 2015-08-29 at 14:49 +0200, Oleg Nesterov wrote:
> > On 08/28, Eric Dumazet wrote:
> > >
> > > From: Eric Dumazet <edumazet@google.com>
> > >
> > > In commit f341861fb0b ("task_work: add a scheduling point in
> > > task_work_run()") I fixed a latency problem adding a cond_resched()
> > > call.
> > >
> > > Later, commit ac3d0da8f329 added yet another loop to reverse a list,
> > > bringing back the latency spike :
> > >
> > > I've seen in some cases this loop taking 275 ms, if for example a
> > > process with 2,000,000 files is killed.
> > >
> > > We could add yet another cond_resched() in the reverse loop,
> >
> > Can't we do this?
>
> Well, I stated in the changelog we could. Obviously we can.
>
> Adding 275 ms of pure overhead to perform this list reversal for files
> to be closed is quite unfortunate.
Well, if the first loop takes 275 ms, then probably the next one which
actually does a lot of __fput's takes much, much more time, so perhaps
these 275 ms are not very noticable. Ignoring the latency problem.
But of course, this is not good, I agree. Please see below.
> > Fifo just looks more sane to me.
>
> Well, files are closed in a random order. These are the main user of
> this stuff.
This is the most "heavy" user. But task_works is the generic API.
> Now we also could question why we needed commit
> 4a9d4b024a3102fc083c925c242d98ac27b1c5f6 ("switch fput to task_work_add
> ") since it seems quite an overhead at task exit with 10^6 of files to
> close.
How about the patch below? I didn't try to test it yet, but since
filp_close() does ->flush() I think __fput_sync() should be safe here.
Al, what do you think?
Oleg.
--- x/fs/file_table.c
+++ x/fs/file_table.c
@@ -292,11 +292,8 @@ void fput(struct file *file)
*/
void __fput_sync(struct file *file)
{
- if (atomic_long_dec_and_test(&file->f_count)) {
- struct task_struct *task = current;
- BUG_ON(!(task->flags & PF_KTHREAD));
+ if (atomic_long_dec_and_test(&file->f_count))
__fput(file);
- }
}
EXPORT_SYMBOL(fput);
--- x/fs/open.c
+++ x/fs/open.c
@@ -1074,7 +1074,7 @@ int filp_close(struct file *filp, fl_owner_t id)
dnotify_flush(filp, id);
locks_remove_posix(filp, id);
}
- fput(filp);
+ __fput_sync(filp);
return retval;
}
next prev parent reply other threads:[~2015-08-31 12:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-29 2:42 [PATCH] task_work: remove fifo ordering guarantee Eric Dumazet
2015-08-29 3:19 ` Linus Torvalds
2015-08-29 9:22 ` Ingo Molnar
2015-08-29 12:54 ` Oleg Nesterov
2015-08-31 6:02 ` Ingo Molnar
2015-08-31 12:51 ` Oleg Nesterov
2015-08-29 12:49 ` Oleg Nesterov
2015-08-29 13:57 ` Eric Dumazet
2015-08-29 14:11 ` Eric Dumazet
2015-08-29 17:08 ` Linus Torvalds
2015-08-31 5:22 ` yalin wang
2015-09-05 5:19 ` Al Viro
2015-08-31 12:44 ` Oleg Nesterov
2015-09-05 5:12 ` Al Viro
2015-09-05 5:42 ` Al Viro
2015-09-05 20:46 ` Linus Torvalds
2015-08-31 12:05 ` Oleg Nesterov [this message]
2015-09-05 5:35 ` Al Viro
2015-09-07 12:27 ` [PATCH?] fput: don't abuse task_work_add() too much Oleg Nesterov
2015-09-07 13:49 ` [PATCH? v2] " Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150831120525.GA31015@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maze@google.com \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.