All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Jeons <simon.jeons@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>,
	Shaohua Li <shli@kernel.org>,
	lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
	Rik van Riel <riel@redhat.com>
Subject: Re: [LSF/MM TOPIC]swap improvements for fast SSD
Date: Thu, 24 Jan 2013 02:29:52 -0600	[thread overview]
Message-ID: <1359016192.2866.1.camel@kernel> (raw)
In-Reply-To: <20130124014059.GA22654@blaptop>

On Thu, 2013-01-24 at 10:40 +0900, Minchan Kim wrote:
> Hi Seth,
> 
> On Wed, Jan 23, 2013 at 01:04:25PM -0600, Seth Jennings wrote:
> > On 01/23/2013 01:58 AM, Minchan Kim wrote:
> > > Currently, the page table entries that have swapped out pages
> > > associated with them contain a swap entry, pointing directly
> > > at the swap device and swap slot containing the data. Meanwhile,
> > > the swap count lives in a separate array.
> > > 
> > > The redesign we are considering moving the swap entry to the
> > > page cache radix tree for the swapper_space and having the pte
> > > contain only the offset into the swapper_space.  The swap count
> > > info can also fit inside the swapper_space page cache radix
> > > tree (at least on 64 bits - on 32 bits we may need to get
> > > creative or accept a smaller max amount of swap space).
> > 
> > Correct me if I'm wrong, but this recent patchset creating a
> > swapper_space per type would mess this up right?  The offset alone
> > would no longer be sufficient to access the proper swapper_space.
> 
> If I understand Rik's idea correctly, it doesn't mess up. Because we already
> have used (swp_type, swp_offset) as offset of swapper_space so although
> he mentioned "pte contains only the offset into the swapper_space",
> it doesn't mean we will store only swp_offset in pte but store offset of
> swapper_space in pte.
> 
> old :
>         do_swap_page
>         swp_entry_t entry = pte_to_swp_entry(pte);
>         if (!lookup_swap_cache(entry))
>                 swapin_readahead(entry)
> 
> New :
>         do_swap_page
>         pgoff_t offset = pte_to_swp_offset(pte)
>         if (!lookup_swap_cache(offset)) {
>                 swp_entry_t entry = offset_to_swp_entry(offset);
>                 swapin_readahead(entry);
>         }
> 

Since Shaohua change the logic to each swap partition have one
address_space, the idea mentioned above can't work any more, correct?   

> IOW, entry of old and offset of new would be same vaule.
> 
> > 
> > Why not just continue to store the entire swap entry (type and offset)
> > in the pte?  Where you planning to use the type space in the pte for
> > something else?
> 
> No plan if I didn't miss something. :)
> 
> > 
> > Seth
> > 
> > --
> > 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>
> 


--
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>

  reply	other threads:[~2013-01-24  8:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22  6:53 [LSF/MM TOPIC]swap improvements for fast SSD Shaohua Li
2013-01-23  7:58 ` Minchan Kim
2013-01-23 19:04   ` Seth Jennings
2013-01-24  1:40     ` Minchan Kim
2013-01-24  8:29       ` Simon Jeons [this message]
2013-01-24  2:02   ` Shaohua Li
2013-01-24  7:52   ` Simon Jeons
2013-01-24  9:09   ` Simon Jeons
2013-01-26  4:40     ` Kyungmin Park
2013-01-27  0:26       ` Simon Jeons
2013-01-27 14:18       ` Shaohua Li
2013-01-28  7:37         ` Kyungmin Park
2013-02-01 12:37           ` Kyungmin Park
2013-02-04  4:56         ` Hugh Dickins
2013-02-19  6:15           ` Shaohua Li
2013-02-19 19:41             ` Hugh Dickins
2013-04-05  0:17   ` Simon Jeons
2013-04-05  8:08     ` Minchan Kim
2013-01-23 16:56 ` Seth Jennings
2013-01-24  6:28 ` Simon Jeons
2013-03-15  9:39 ` Simon Jeons
2013-03-18 10:38   ` Bob Liu
2013-03-19  1:27     ` Shaohua Li
2013-03-19  1:32       ` Simon Jeons
2013-03-19  5:57         ` Shaohua Li
2013-03-19  6:10           ` Simon Jeons
2013-03-19  4:25       ` Wanpeng Li
2013-03-19  4:25       ` Wanpeng Li
2013-04-28  8:12 ` Simon Jeons
     [not found] <766b9855-adf5-47ce-9484-971f88ff0e54@default>
2013-01-23 23:05 ` Dan Magenheimer
2013-01-24  2:11   ` Shaohua Li

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=1359016192.2866.1.camel@kernel \
    --to=simon.jeons@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=shli@kernel.org \
    --cc=sjenning@linux.vnet.ibm.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.