[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170112164717.GA26499@linux.intel.com>
Date: Thu, 12 Jan 2017 08:47:18 -0800
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"Huang, Ying" <ying.huang@...el.com>, dave.hansen@...el.com,
aaron.lu@...el.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Hugh Dickins <hughd@...gle.com>,
Shaohua Li <shli@...nel.org>, Minchan Kim <minchan@...nel.org>,
Rik van Riel <riel@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Vladimir Davydov <vdavydov.dev@...il.com>,
Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>,
Hillf Danton <hillf.zj@...baba-inc.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH v5 3/9] mm/swap: Split swap cache into 64MB trunks
On Wed, Jan 11, 2017 at 03:19:37PM -0800, Andi Kleen wrote:
> > 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?
I agree that this approach is a bit hacky. However, it is pretty
effective and simple. If later on we come up with a better solution to
scale modfication of the radix tree, we can collapse the radix trees.
I think developing a scalable radix tree with write modifications will
take quite a while and is a non-trivial effort. With almost memory speed
SSDs coming on the market soon, I think having a workable solution now
and optimizing it for long term is reasonabale.
Tim
Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)
Powered by blists - more mailing lists