[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120821220351.GA4463@p183.telecom.by>
Date: Wed, 22 Aug 2012 01:03:52 +0300
From: Alexey Dobriyan <adobriyan@...il.com>
To: Nathan Zimmer <nzimmer@....com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [RFC] Move kfree outside pde_unload_lock
On Tue, Aug 21, 2012 at 03:54:54PM -0500, Nathan Zimmer wrote:
> I am currently tracking a hotlock reported by a customer on a large, 512 cores,
> system, I am currently running 3.6.0 rc1 but the issue looks like it has been
> this way for a very long time.
> The offending lock is proc_dir_entry->pde_unload_lock.
>
> In proc_reg_release we are doing a kfree under the spinlock which is ok but it
> means we are holding the lock longer then required. Scaling improved when I
> moved kfree out.
It's OK to move it out.
Acked-by: Alexey Dobriyan <adobriyan@...il.com>
> Also shouldn't the comment on pde_unload_lock also note that pde_openers and
> pde_unload_completion are both used under the lock?
Yeah, why not.
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -403,9 +403,11 @@ static int proc_reg_release(struct inode *inode, struct file *file)
> release = pde->proc_fops->release;
> if (pdeo) {
> list_del(&pdeo->lh);
> - kfree(pdeo);
> }
> spin_unlock(&pde->pde_unload_lock);
> + if (pdeo) {
> + kfree(pdeo);
> + }
>
> if (release)
> rv = release(inode, file);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists