From: Andi Kleen <ak@linux.intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
"Huang, Ying" <ying.huang@intel.com>,
dave.hansen@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>, Minchan Kim <minchan@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>
Subject: Re: [PATCH v5 3/9] mm/swap: Split swap cache into 64MB trunks
Date: Wed, 11 Jan 2017 15:19:37 -0800 [thread overview]
Message-ID: <20170111231937.GH8388@tassilo.jf.intel.com> (raw)
In-Reply-To: <20170111150940.25d951a121a62e1b7eff6f8d@linux-foundation.org>
> Switching from a single radix-tree to an array of radix-trees to reduce
> contention seems a bit hacky. That we can do this and have everything
> continue to work tells me that we're simply using an inappropriate data
> structure to hold this info.
What would you use instead?
A tree with fine grained locking?
FWIW too fine grained locking (e.g. on every node) is usually a bad idea:
it slows down the single thread performance and it causes much more overhead
when there is actual contention because too much time is spent bouncing cache
lines around.
So I actually like the "a little bit more fine grained, but not too much"
approach.
Or a hash table?
Not sure if this would work here.
-Andi
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@linux.intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
"Huang, Ying" <ying.huang@intel.com>,
dave.hansen@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>, Minchan Kim <minchan@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>
Subject: Re: [PATCH v5 3/9] mm/swap: Split swap cache into 64MB trunks
Date: Wed, 11 Jan 2017 15:19:37 -0800 [thread overview]
Message-ID: <20170111231937.GH8388@tassilo.jf.intel.com> (raw)
In-Reply-To: <20170111150940.25d951a121a62e1b7eff6f8d@linux-foundation.org>
> Switching from a single radix-tree to an array of radix-trees to reduce
> contention seems a bit hacky. That we can do this and have everything
> continue to work tells me that we're simply using an inappropriate data
> structure to hold this info.
What would you use instead?
A tree with fine grained locking?
FWIW too fine grained locking (e.g. on every node) is usually a bad idea:
it slows down the single thread performance and it causes much more overhead
when there is actual contention because too much time is spent bouncing cache
lines around.
So I actually like the "a little bit more fine grained, but not too much"
approach.
Or a hash table?
Not sure if this would work here.
-Andi
--
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>
next prev parent reply other threads:[~2017-01-11 23:19 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-11 17:55 [PATCH v5 0/9] mm/swap: Regular page swap optimizations Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-11 17:55 ` [PATCH v5 1/9] mm/swap: Fix kernel message in swap_info_get() Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-11 17:55 ` [PATCH v5 2/9] mm/swap: Add cluster lock Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-11 23:00 ` Andrew Morton
2017-01-11 23:00 ` Andrew Morton
2017-01-11 23:07 ` Jonathan Corbet
2017-01-11 23:07 ` Jonathan Corbet
2017-01-11 23:15 ` Andrew Morton
2017-01-11 23:15 ` Andrew Morton
2017-01-12 1:47 ` Huang, Ying
2017-01-12 1:47 ` Huang, Ying
2017-01-12 1:58 ` Andrew Morton
2017-01-12 1:58 ` Andrew Morton
2017-01-12 2:51 ` Huang, Ying
2017-01-12 2:51 ` Huang, Ying
2017-01-14 4:37 ` [Update][PATCH " Huang, Ying
2017-01-14 4:37 ` Huang, Ying
2017-01-12 1:23 ` [PATCH " Huang, Ying
2017-01-12 1:23 ` Huang, Ying
2017-01-11 17:55 ` [PATCH v5 3/9] mm/swap: Split swap cache into 64MB trunks Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-11 23:09 ` Andrew Morton
2017-01-11 23:09 ` Andrew Morton
2017-01-11 23:19 ` Andi Kleen [this message]
2017-01-11 23:19 ` Andi Kleen
2017-01-12 16:47 ` Tim Chen
2017-01-11 17:55 ` [PATCH v5 4/9] mm/swap: skip read ahead for unreferenced swap slots Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-11 17:55 ` [PATCH v5 5/9] mm/swap: Allocate swap slots in batches Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-11 17:55 ` [PATCH v5 6/9] mm/swap: Free swap slots in batch Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-11 17:55 ` [PATCH v5 7/9] mm/swap: Add cache for swap slots allocation Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-17 2:55 ` [Update][PATCH " Huang, Ying
2017-01-17 2:55 ` Huang, Ying
2017-01-17 10:16 ` Michal Hocko
2017-01-17 10:16 ` Michal Hocko
2017-01-17 17:24 ` Chen, Tim C
2017-01-17 17:24 ` Chen, Tim C
2017-01-17 20:03 ` Michal Hocko
2017-01-17 20:03 ` Michal Hocko
2017-01-17 20:31 ` Chen, Tim C
2017-01-17 20:31 ` Chen, Tim C
2017-01-17 21:42 ` Tim Chen
2017-01-18 12:45 ` Michal Hocko
2017-01-18 12:45 ` Michal Hocko
2017-01-18 18:03 ` Tim Chen
2017-01-18 18:15 ` Michal Hocko
2017-01-18 18:15 ` Michal Hocko
2017-01-11 17:55 ` [PATCH v5 8/9] mm/swap: Enable swap slots cache usage Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-11 17:55 ` [PATCH v5 9/9] mm/swap: Skip readahead only when swap slot cache is enabled Tim Chen
2017-01-11 17:55 ` Tim Chen
2017-01-16 12:02 ` [PATCH v5 0/9] mm/swap: Regular page swap optimizations Michal Hocko
2017-01-16 12:02 ` Michal Hocko
2017-01-17 1:06 ` Huang, Ying
2017-01-17 1:06 ` Huang, Ying
2017-01-17 7:49 ` Michal Hocko
2017-01-17 7:49 ` Michal Hocko
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=20170111231937.GH8388@tassilo.jf.intel.com \
--to=ak@linux.intel.com \
--cc=aarcange@redhat.com \
--cc=aaron.lu@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.