All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <boaz@plexistor.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>,
	linux-kernel@vger.kernel.org, axboe@kernel.dk, riel@redhat.com,
	linux-nvdimm@lists.01.org, linux-mm@kvack.org, mgorman@suse.de,
	torvalds@linux-foundation.org
Subject: Re: [PATCH v5 2/5] allow mapping page-less memremaped areas into KVA
Date: Thu, 13 Aug 2015 18:29:33 +0300	[thread overview]
Message-ID: <55CCB7DD.7080005@plexistor.com> (raw)
In-Reply-To: <55CCAE57.20009@plexistor.com>

On 08/13/2015 05:48 PM, Boaz Harrosh wrote:
<>
> There is already an object that holds a relationship of physical
> to Kernel-virtual. It is called a memory-section. Why not just
> widen its definition?
> 

BTW: Regarding the "widen its definition"

I was thinking of two possible new models here:
[1-A page-less memory section]
- Keep the 64bit phisical-to-kernel_virtual hard coded relationship
- Allocate a section-object, but this section object does not have any
  pages, its only the header. (You need it for the pmd/pmt thing)

  Lots of things just work now if you make sure you do not go through
  a page struct. This needs no extra work I have done this in the past
  all you need is to do your ioremap through the map_kernel_range_noflush(__va(), ....)

[2- Small pages-struct]

- Like above, but each entry in the new section object is small one-ulong size
  holding just flags.

 Then if !(p->flags & PAGE_SPECIAL) page = container_of(p, struct page, flags)

 This model is good because you actually have your pfn_to_page and page_to_pfn
 and need not touch sg-list or bio. But only 8 bytes per frame instead of 64 bytes


But I still think that the best long-term model is the variable size pages
where a page* can be 2M or 1G. Again an extra flag and a widen section definition.
Is about time we move to bigger pages, throughout but still keep the 4k
page-cache-dirty granularity.

Thanks
Boaz

--
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: Boaz Harrosh <boaz@plexistor.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>,
	linux-kernel@vger.kernel.org, axboe@kernel.dk, riel@redhat.com,
	linux-nvdimm@ml01.01.org, linux-mm@kvack.org, mgorman@suse.de,
	torvalds@linux-foundation.org
Subject: Re: [PATCH v5 2/5] allow mapping page-less memremaped areas into KVA
Date: Thu, 13 Aug 2015 18:29:33 +0300	[thread overview]
Message-ID: <55CCB7DD.7080005@plexistor.com> (raw)
In-Reply-To: <55CCAE57.20009@plexistor.com>

On 08/13/2015 05:48 PM, Boaz Harrosh wrote:
<>
> There is already an object that holds a relationship of physical
> to Kernel-virtual. It is called a memory-section. Why not just
> widen its definition?
> 

BTW: Regarding the "widen its definition"

I was thinking of two possible new models here:
[1-A page-less memory section]
- Keep the 64bit phisical-to-kernel_virtual hard coded relationship
- Allocate a section-object, but this section object does not have any
  pages, its only the header. (You need it for the pmd/pmt thing)

  Lots of things just work now if you make sure you do not go through
  a page struct. This needs no extra work I have done this in the past
  all you need is to do your ioremap through the map_kernel_range_noflush(__va(), ....)

[2- Small pages-struct]

- Like above, but each entry in the new section object is small one-ulong size
  holding just flags.

 Then if !(p->flags & PAGE_SPECIAL) page = container_of(p, struct page, flags)

 This model is good because you actually have your pfn_to_page and page_to_pfn
 and need not touch sg-list or bio. But only 8 bytes per frame instead of 64 bytes


But I still think that the best long-term model is the variable size pages
where a page* can be 2M or 1G. Again an extra flag and a widen section definition.
Is about time we move to bigger pages, throughout but still keep the 4k
page-cache-dirty granularity.

Thanks
Boaz


  reply	other threads:[~2015-08-13 15:29 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-13  3:00 [PATCH v5 0/5] introduce __pfn_t for unmapped pfn I/O and DAX lifetime Dan Williams
2015-08-13  3:00 ` Dan Williams
2015-08-13  3:01 ` [PATCH v5 1/5] mm: move __phys_to_pfn and __pfn_to_phys to asm/generic/memory_model.h Dan Williams
2015-08-13  3:01   ` Dan Williams
2015-08-13  3:01 ` [PATCH v5 2/5] allow mapping page-less memremaped areas into KVA Dan Williams
2015-08-13  3:01   ` Dan Williams
2015-08-13  5:58   ` Boaz Harrosh
2015-08-13  5:58     ` Boaz Harrosh
2015-08-13 12:57     ` Dan Williams
2015-08-13 12:57       ` Dan Williams
2015-08-13 13:23       ` Boaz Harrosh
2015-08-13 13:23         ` Boaz Harrosh
2015-08-13 14:41         ` Christoph Hellwig
2015-08-13 14:41           ` Christoph Hellwig
2015-08-13 15:01           ` Boaz Harrosh
2015-08-13 15:01             ` Boaz Harrosh
2015-08-13 14:37     ` Christoph Hellwig
2015-08-13 14:37       ` Christoph Hellwig
2015-08-13 14:48       ` Boaz Harrosh
2015-08-13 14:48         ` Boaz Harrosh
2015-08-13 15:29         ` Boaz Harrosh [this message]
2015-08-13 15:29           ` Boaz Harrosh
2015-08-13 17:37         ` Dave Hansen
2015-08-13 17:37           ` Dave Hansen
2015-08-13 17:35   ` Matthew Wilcox
2015-08-13 17:35     ` Matthew Wilcox
2015-08-13 18:15     ` Dan Williams
2015-08-13 18:15       ` Dan Williams
2015-08-13  3:01 ` [PATCH v5 3/5] dax: drop size parameter to ->direct_access() Dan Williams
2015-08-13  3:01   ` Dan Williams
2015-08-13  3:01 ` [PATCH v5 4/5] dax: fix mapping lifetime handling, convert to __pfn_t + kmap_atomic_pfn_t() Dan Williams
2015-08-13  3:01   ` Dan Williams
2015-08-13  6:26   ` Boaz Harrosh
2015-08-13  6:26     ` Boaz Harrosh
2015-08-13 15:21     ` Dan Williams
2015-08-13 15:21       ` Dan Williams
2015-08-13 16:34       ` Boaz Harrosh
2015-08-13 16:34         ` Boaz Harrosh
2015-08-13 18:51         ` Dan Williams
2015-08-13 18:51           ` Dan Williams
2015-08-13  3:01 ` [PATCH v5 5/5] scatterlist: convert to __pfn_t Dan Williams
2015-08-13  3:01   ` Dan Williams

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=55CCB7DD.7080005@plexistor.com \
    --to=boaz@plexistor.com \
    --cc=axboe@kernel.dk \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mgorman@suse.de \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /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.