From: Jan Kara <jack@suse.cz>
To: Minchan Kim <minchan@kernel.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ying Huang <ying.huang@intel.com>,
dave.hansen@intel.com, ak@linux.intel.com, aaron.lu@intel.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Hugh Dickins <hughd@google.com>, Shaohua Li <shli@kernel.org>,
Rik van Riel <riel@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Hillf Danton <hillf.zj@alibaba-inc.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Jonathan Corbet <corbet@lwn.net>,
jack@suse.cz
Subject: Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations
Date: Mon, 2 Jan 2017 16:48:41 +0100 [thread overview]
Message-ID: <20170102154841.GG18058@quack2.suse.cz> (raw)
In-Reply-To: <20161227074503.GA10616@bbox>
Hi,
On Tue 27-12-16 16:45:03, Minchan Kim wrote:
> > Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
> > the rate that we have to contende for the radix tree.
>
> To me, it's rather hacky. I think it might be common problem for page cache
> so can we think another generalized way like range_lock? Ccing Jan.
I agree on the hackyness of the patch and that page cache would suffer with
the same contention (although the files are usually smaller than swap so it
would not be that visible I guess). But I don't see how range lock would
help here - we need to serialize modifications of the tree structure itself
and that is difficult to achieve with the range lock. So what you would
need is either a different data structure for tracking swap cache entries
or a finer grained locking of the radix tree.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Minchan Kim <minchan@kernel.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ying Huang <ying.huang@intel.com>,
dave.hansen@intel.com, ak@linux.intel.com, aaron.lu@intel.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Hugh Dickins <hughd@google.com>, Shaohua Li <shli@kernel.org>,
Rik van Riel <riel@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Hillf Danton <hillf.zj@alibaba-inc.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Jonathan Corbet <corbet@lwn.net>,
jack@suse.cz
Subject: Re: [PATCH v4 0/9] mm/swap: Regular page swap optimizations
Date: Mon, 2 Jan 2017 16:48:41 +0100 [thread overview]
Message-ID: <20170102154841.GG18058@quack2.suse.cz> (raw)
In-Reply-To: <20161227074503.GA10616@bbox>
Hi,
On Tue 27-12-16 16:45:03, Minchan Kim wrote:
> > Patch 3 splits the swap cache radix tree into 64MB chunks, reducing
> > the rate that we have to contende for the radix tree.
>
> To me, it's rather hacky. I think it might be common problem for page cache
> so can we think another generalized way like range_lock? Ccing Jan.
I agree on the hackyness of the patch and that page cache would suffer with
the same contention (although the files are usually smaller than swap so it
would not be that visible I guess). But I don't see how range lock would
help here - we need to serialize modifications of the tree structure itself
and that is difficult to achieve with the range lock. So what you would
need is either a different data structure for tracking swap cache entries
or a finer grained locking of the radix tree.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2017-01-02 15:48 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-09 21:09 [PATCH v4 0/9] mm/swap: Regular page swap optimizations Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-09 21:09 ` [PATCH v4 1/9] mm/swap: Fix kernel message in swap_info_get() Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-09 21:09 ` [PATCH v4 2/9] mm/swap: Add cluster lock Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-09 21:09 ` [PATCH v4 3/9] mm/swap: Split swap cache into 64MB trunks Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-09 21:09 ` [PATCH v4 4/9] mm/swap: skip read ahead for unreferenced swap slots Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-09 21:09 ` [PATCH v4 5/9] mm/swap: Allocate swap slots in batches Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-09 21:09 ` [PATCH v4 6/9] mm/swap: Free swap slots in batch Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-09 21:09 ` [PATCH v4 7/9] mm/swap: Add cache for swap slots allocation Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-09 21:09 ` [PATCH v4 8/9] mm/swap: Enable swap slots cache usage Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-09 21:09 ` [PATCH v4 9/9] mm/swap: Skip readahead only when swap slot cache is enabled Tim Chen
2016-12-09 21:09 ` Tim Chen
2016-12-27 7:45 ` [PATCH v4 0/9] mm/swap: Regular page swap optimizations Minchan Kim
2016-12-27 7:45 ` Minchan Kim
2016-12-28 1:54 ` Huang, Ying
2016-12-28 1:54 ` Huang, Ying
2016-12-28 2:37 ` Minchan Kim
2016-12-28 2:37 ` Minchan Kim
2016-12-28 3:15 ` Huang, Ying
2016-12-28 3:15 ` Huang, Ying
2016-12-28 3:31 ` Huang, Ying
2016-12-28 3:31 ` Huang, Ying
2016-12-28 3:53 ` Minchan Kim
2016-12-28 3:53 ` Minchan Kim
2016-12-28 4:56 ` Huang, Ying
2016-12-28 4:56 ` Huang, Ying
2017-01-02 15:48 ` Jan Kara [this message]
2017-01-02 15:48 ` Jan Kara
2017-01-03 4:34 ` Minchan Kim
2017-01-03 4:34 ` Minchan Kim
2017-01-03 5:43 ` Huang, Ying
2017-01-03 5:43 ` Huang, Ying
2017-01-05 6:15 ` Minchan Kim
2017-01-05 6:15 ` Minchan Kim
2017-01-03 17:47 ` Tim Chen
2017-01-03 17:47 ` Tim Chen
2017-01-05 1:33 ` Huang, Ying
2017-01-05 1:33 ` Huang, Ying
2017-01-05 6:32 ` Minchan Kim
2017-01-05 6:32 ` Minchan Kim
2017-01-05 6:44 ` Huang, Ying
2017-01-05 6:44 ` Huang, Ying
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=20170102154841.GG18058@quack2.suse.cz \
--to=jack@suse.cz \
--cc=aarcange@redhat.com \
--cc=aaron.lu@intel.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=hillf.zj@alibaba-inc.com \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=shli@kernel.org \
--cc=tim.c.chen@linux.intel.com \
--cc=vdavydov.dev@gmail.com \
--cc=ying.huang@intel.com \
/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.