On 03/24/2015 05:41 AM, Boaz Harrosh wrote:
> On 03/23/2015 05:19 PM, Rik van Riel wrote:
>> There are two things going on here:
>>
>> 1) You want to keep using struct page for now, while there are
>>subsystems that require it. This is perfectly legitimate.
>>
>> 2) Matthew and Dan are
On 03/23/2015 05:19 PM, Rik van Riel wrote:
>>> Michael Tsirkin and I have been doing some thinking about what
>>> it would take to allocate struct pages per 2MB area permanently,
>>> and allocate additional struct pages for 4kB pages on demand,
>>> when a 2MB area is broken up into 4kB pages.
>>
On 03/23/2015 05:19 PM, Rik van Riel wrote:
Michael Tsirkin and I have been doing some thinking about what
it would take to allocate struct pages per 2MB area permanently,
and allocate additional struct pages for 4kB pages on demand,
when a 2MB area is broken up into 4kB pages.
My thoughts
On 03/24/2015 05:41 AM, Boaz Harrosh wrote:
On 03/23/2015 05:19 PM, Rik van Riel wrote:
There are two things going on here:
1) You want to keep using struct page for now, while there are
subsystems that require it. This is perfectly legitimate.
2) Matthew and Dan are changing over some
On Mon, Mar 23, 2015 at 11:19:07AM -0400, Rik van Riel wrote:
> There are two things going on here:
>
> 1) You want to keep using struct page for now, while there are
>subsystems that require it. This is perfectly legitimate.
>
> 2) Matthew and Dan are changing over some subsystems to no
On 03/22/2015 11:51 AM, Boaz Harrosh wrote:
> On 03/20/2015 06:21 PM, Rik van Riel wrote:
>> On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
>>
>>> 1. Construct struct pages for persistent memory
>>> 1a. Permanently
>>> 1b. While the pages are under I/O
>>
>> Michael Tsirkin and I have been doing
On 03/22/2015 11:51 AM, Boaz Harrosh wrote:
On 03/20/2015 06:21 PM, Rik van Riel wrote:
On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
1. Construct struct pages for persistent memory
1a. Permanently
1b. While the pages are under I/O
Michael Tsirkin and I have been doing some thinking about
On Mon, Mar 23, 2015 at 11:19:07AM -0400, Rik van Riel wrote:
There are two things going on here:
1) You want to keep using struct page for now, while there are
subsystems that require it. This is perfectly legitimate.
2) Matthew and Dan are changing over some subsystems to no longer
On 03/22/2015 07:22 PM, Dan Williams wrote:
> On Sun, Mar 22, 2015 at 10:06 AM, Boaz Harrosh wrote:
<>
>>
>> Moving to pfn's only means that all this unnamed code above that
>> "relies on struct page being PAGE_SIZE" is now not allowed to
>> interfaced with bio and sg list. Which in current code
On 03/19/2015 10:59 PM, Dan Williams wrote:
>
> At least for block-i/o it seems the only place we really need struct
> page infrastructure is for kmap(). Given we already need a kmap_pfn()
> solution for option 2 a "dynamic allocation" stop along that
> development path may just naturally fall
On Sun, Mar 22, 2015 at 10:06 AM, Boaz Harrosh wrote:
> On 03/20/2015 11:08 PM, Rik van Riel wrote:
>> On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
> <>
>>> There's a lot of code out there that relies on struct page being PAGE_SIZE
>>> bytes. I'm cool with replacing 'struct page' with 'struct
On 03/20/2015 11:08 PM, Rik van Riel wrote:
> On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
<>
>> There's a lot of code out there that relies on struct page being PAGE_SIZE
>> bytes. I'm cool with replacing 'struct page' with 'struct superpage'
>> [1] in the biovec and auditing all of the code
On 03/19/2015 08:17 PM, Christoph Hellwig wrote:
<>
>
> In addition to the options there's also a time line. At least for the
> short term where we want to get something going 1a seems like the
> absolutely be option. It works perfectly fine for the lots of small
> capacity dram-like nvdimms,
On 03/20/2015 10:31 PM, Matthew Wilcox wrote:
<>
>
> There's a lot of code out there that relies on struct page being PAGE_SIZE
> bytes.
Not so much really. Not at the lower end of the stack. You can actually feed
a
vp = kmalloc(64K);
bv_page = virt_to_page(vp)
bv_len
On 03/20/2015 06:21 PM, Rik van Riel wrote:
> On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
>
>> 1. Construct struct pages for persistent memory
>> 1a. Permanently
>> 1b. While the pages are under I/O
>
> Michael Tsirkin and I have been doing some thinking about what
> it would take to allocate
On 03/20/2015 05:56 PM, Rik van Riel wrote:
> On 03/18/2015 10:38 AM, Boaz Harrosh wrote:
>> On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
>
I'm not the one afraid of hard work, if it was for a good cause, but for
what?
really for what? The block layer, and RDMA, and networking,
On 03/19/2015 09:59 PM, Andrew Morton wrote:
> On Thu, 19 Mar 2015 17:54:15 +0200 Boaz Harrosh wrote:
>
>> On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
>> <>
>>>
>>> Dan missed "Support O_DIRECT to a mapped DAX file". More generally, if we
>>> want to be able to do any kind of I/O directly to
On 03/19/2015 09:59 PM, Andrew Morton wrote:
On Thu, 19 Mar 2015 17:54:15 +0200 Boaz Harrosh b...@plexistor.com wrote:
On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
Dan missed Support O_DIRECT to a mapped DAX file. More generally, if we
want to be able to do any kind of I/O directly to
On 03/20/2015 05:56 PM, Rik van Riel wrote:
On 03/18/2015 10:38 AM, Boaz Harrosh wrote:
On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
I'm not the one afraid of hard work, if it was for a good cause, but for
what?
really for what? The block layer, and RDMA, and networking, and spline,
and
On 03/20/2015 06:21 PM, Rik van Riel wrote:
On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
1. Construct struct pages for persistent memory
1a. Permanently
1b. While the pages are under I/O
Michael Tsirkin and I have been doing some thinking about what
it would take to allocate struct
On 03/19/2015 08:17 PM, Christoph Hellwig wrote:
In addition to the options there's also a time line. At least for the
short term where we want to get something going 1a seems like the
absolutely be option. It works perfectly fine for the lots of small
capacity dram-like nvdimms, and it
On 03/20/2015 11:08 PM, Rik van Riel wrote:
On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
There's a lot of code out there that relies on struct page being PAGE_SIZE
bytes. I'm cool with replacing 'struct page' with 'struct superpage'
[1] in the biovec and auditing all of the code which
On Sun, Mar 22, 2015 at 10:06 AM, Boaz Harrosh b...@plexistor.com wrote:
On 03/20/2015 11:08 PM, Rik van Riel wrote:
On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
There's a lot of code out there that relies on struct page being PAGE_SIZE
bytes. I'm cool with replacing 'struct page' with
On 03/19/2015 10:59 PM, Dan Williams wrote:
At least for block-i/o it seems the only place we really need struct
page infrastructure is for kmap(). Given we already need a kmap_pfn()
solution for option 2 a dynamic allocation stop along that
development path may just naturally fall out.
On 03/20/2015 10:31 PM, Matthew Wilcox wrote:
There's a lot of code out there that relies on struct page being PAGE_SIZE
bytes.
Not so much really. Not at the lower end of the stack. You can actually feed
a
vp = kmalloc(64K);
bv_page = virt_to_page(vp)
bv_len = 64k
On 03/22/2015 07:22 PM, Dan Williams wrote:
On Sun, Mar 22, 2015 at 10:06 AM, Boaz Harrosh b...@plexistor.com wrote:
Moving to pfn's only means that all this unnamed code above that
relies on struct page being PAGE_SIZE is now not allowed to
interfaced with bio and sg list. Which in current
On 20/03/15 20:31, Matthew Wilcox wrote:
> Ah! I've looked at that a couple of times as well. I asked our database
> performance team what impact freeing up the memmap would have on their
> performance. They told me that doubling the amount of memory generally
> resulted in approximately a 40%
On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
> On Fri, Mar 20, 2015 at 12:21:34PM -0400, Rik van Riel wrote:
>> On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
>>
>>> 1. Construct struct pages for persistent memory
>>> 1a. Permanently
>>> 1b. While the pages are under I/O
>>
>> Michael Tsirkin and
On Fri, Mar 20, 2015 at 12:21:34PM -0400, Rik van Riel wrote:
> On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
>
> > 1. Construct struct pages for persistent memory
> > 1a. Permanently
> > 1b. While the pages are under I/O
>
> Michael Tsirkin and I have been doing some thinking about what
> it
On 19/03/15 19:59, Andrew Morton wrote:
> This is all contingent upon the prevalence of machines which have vast
> amounts of nv memory and relatively small amounts of regular memory.
> How confident are we that this really is the future?
Somewhat off-topic, but it's also the past. I can't help
On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
> 1. Construct struct pages for persistent memory
> 1a. Permanently
> 1b. While the pages are under I/O
Michael Tsirkin and I have been doing some thinking about what
it would take to allocate struct pages per 2MB area permanently,
and allocate
On 03/18/2015 10:38 AM, Boaz Harrosh wrote:
> On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
>>> I'm not the one afraid of hard work, if it was for a good cause, but for
>>> what?
>>> really for what? The block layer, and RDMA, and networking, and spline, and
>>> what
>>> ever the heck any one
On 03/18/2015 10:38 AM, Boaz Harrosh wrote:
On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
I'm not the one afraid of hard work, if it was for a good cause, but for
what?
really for what? The block layer, and RDMA, and networking, and spline, and
what
ever the heck any one wants to imagine
On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
On Fri, Mar 20, 2015 at 12:21:34PM -0400, Rik van Riel wrote:
On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
1. Construct struct pages for persistent memory
1a. Permanently
1b. While the pages are under I/O
Michael Tsirkin and I have been doing
On 19/03/15 19:59, Andrew Morton wrote:
This is all contingent upon the prevalence of machines which have vast
amounts of nv memory and relatively small amounts of regular memory.
How confident are we that this really is the future?
Somewhat off-topic, but it's also the past. I can't help
On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
1. Construct struct pages for persistent memory
1a. Permanently
1b. While the pages are under I/O
Michael Tsirkin and I have been doing some thinking about what
it would take to allocate struct pages per 2MB area permanently,
and allocate
On Fri, Mar 20, 2015 at 12:21:34PM -0400, Rik van Riel wrote:
On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
1. Construct struct pages for persistent memory
1a. Permanently
1b. While the pages are under I/O
Michael Tsirkin and I have been doing some thinking about what
it would take to
On 20/03/15 20:31, Matthew Wilcox wrote:
Ah! I've looked at that a couple of times as well. I asked our database
performance team what impact freeing up the memmap would have on their
performance. They told me that doubling the amount of memory generally
resulted in approximately a 40%
On Thu, Mar 19, 2015 at 12:59 PM, Andrew Morton
wrote:
> On Thu, 19 Mar 2015 17:54:15 +0200 Boaz Harrosh wrote:
>
>> On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
>> <>
>> >
>> > Dan missed "Support O_DIRECT to a mapped DAX file". More generally, if we
>> > want to be able to do any kind of I/O
On Thu, 19 Mar 2015 17:54:15 +0200 Boaz Harrosh wrote:
> On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
> <>
> >
> > Dan missed "Support O_DIRECT to a mapped DAX file". More generally, if we
> > want to be able to do any kind of I/O directly to persistent memory,
> > and I think we do, we need
On Thu, Mar 19, 2015 at 11:17:25AM -0700, Christoph Hellwig wrote:
> On Thu, Mar 19, 2015 at 09:43:13AM -0400, Matthew Wilcox wrote:
> > 1. Construct struct pages for persistent memory
> > 1a. Permanently
> > 1b. While the pages are under I/O
> > 2. Teach the I/O layers to deal in PFNs instead of
On Thu, Mar 19, 2015 at 09:43:13AM -0400, Matthew Wilcox wrote:
> Dan missed "Support O_DIRECT to a mapped DAX file". More generally, if we
> want to be able to do any kind of I/O directly to persistent memory,
> and I think we do, we need to do one of:
>
> 1. Construct struct pages for
On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
<>
>
> Dan missed "Support O_DIRECT to a mapped DAX file". More generally, if we
> want to be able to do any kind of I/O directly to persistent memory,
> and I think we do, we need to do one of:
>
> 1. Construct struct pages for persistent memory
>
On Wed, Mar 18, 2015 at 01:26:50PM -0700, Andrew Morton wrote:
> On Mon, 16 Mar 2015 16:25:25 -0400 Dan Williams
> wrote:
>
> > Avoid the impending disaster of requiring struct page coverage for what
> > is expected to be ever increasing capacities of persistent memory. In
> > conversations
On Thu, Mar 19, 2015 at 11:17:25AM -0700, Christoph Hellwig wrote:
On Thu, Mar 19, 2015 at 09:43:13AM -0400, Matthew Wilcox wrote:
1. Construct struct pages for persistent memory
1a. Permanently
1b. While the pages are under I/O
2. Teach the I/O layers to deal in PFNs instead of struct
On Thu, 19 Mar 2015 17:54:15 +0200 Boaz Harrosh b...@plexistor.com wrote:
On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
Dan missed Support O_DIRECT to a mapped DAX file. More generally, if we
want to be able to do any kind of I/O directly to persistent memory,
and I think we do, we
On Wed, Mar 18, 2015 at 01:26:50PM -0700, Andrew Morton wrote:
On Mon, 16 Mar 2015 16:25:25 -0400 Dan Williams dan.j.willi...@intel.com
wrote:
Avoid the impending disaster of requiring struct page coverage for what
is expected to be ever increasing capacities of persistent memory. In
On Thu, Mar 19, 2015 at 09:43:13AM -0400, Matthew Wilcox wrote:
Dan missed Support O_DIRECT to a mapped DAX file. More generally, if we
want to be able to do any kind of I/O directly to persistent memory,
and I think we do, we need to do one of:
1. Construct struct pages for persistent
On Thu, Mar 19, 2015 at 12:59 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Thu, 19 Mar 2015 17:54:15 +0200 Boaz Harrosh b...@plexistor.com wrote:
On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
Dan missed Support O_DIRECT to a mapped DAX file. More generally, if we
want to be
On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
Dan missed Support O_DIRECT to a mapped DAX file. More generally, if we
want to be able to do any kind of I/O directly to persistent memory,
and I think we do, we need to do one of:
1. Construct struct pages for persistent memory
1a.
On Mon, 16 Mar 2015 16:25:25 -0400 Dan Williams
wrote:
> Avoid the impending disaster of requiring struct page coverage for what
> is expected to be ever increasing capacities of persistent memory. In
> conversations with Rik van Riel, Mel Gorman, and Jens Axboe at the
> recently concluded
On Wed, Mar 18, 2015 at 3:47 AM, Boaz Harrosh wrote:
> On 03/16/2015 10:25 PM, Dan Williams wrote:
>> Avoid the impending disaster of requiring struct page coverage for what
>> is expected to be ever increasing capacities of persistent memory.
>
> If you are saying "disaster", than we need to
On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
> On Wed, Mar 18, 2015 at 12:47:21PM +0200, Boaz Harrosh wrote:
>> God! Look at this endless list of files and it is only the very beginning.
>> It does not even work and touches only 10% of what will need to be touched
>> for this to work, and very
On Wed, Mar 18, 2015 at 12:47:21PM +0200, Boaz Harrosh wrote:
> God! Look at this endless list of files and it is only the very beginning.
> It does not even work and touches only 10% of what will need to be touched
> for this to work, and very very marginally at that. There will always be
>
On 03/16/2015 10:25 PM, Dan Williams wrote:
> Avoid the impending disaster of requiring struct page coverage for what
> is expected to be ever increasing capacities of persistent memory.
If you are saying "disaster", than we need to believe you. Or is there
a scientific proof for this.
On 03/16/2015 10:25 PM, Dan Williams wrote:
Avoid the impending disaster of requiring struct page coverage for what
is expected to be ever increasing capacities of persistent memory.
If you are saying disaster, than we need to believe you. Or is there
a scientific proof for this.
Actually
On Wed, Mar 18, 2015 at 12:47:21PM +0200, Boaz Harrosh wrote:
God! Look at this endless list of files and it is only the very beginning.
It does not even work and touches only 10% of what will need to be touched
for this to work, and very very marginally at that. There will always be
another
On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
On Wed, Mar 18, 2015 at 12:47:21PM +0200, Boaz Harrosh wrote:
God! Look at this endless list of files and it is only the very beginning.
It does not even work and touches only 10% of what will need to be touched
for this to work, and very very
On Wed, Mar 18, 2015 at 3:47 AM, Boaz Harrosh open...@gmail.com wrote:
On 03/16/2015 10:25 PM, Dan Williams wrote:
Avoid the impending disaster of requiring struct page coverage for what
is expected to be ever increasing capacities of persistent memory.
If you are saying disaster, than we
On Mon, 16 Mar 2015 16:25:25 -0400 Dan Williams dan.j.willi...@intel.com
wrote:
Avoid the impending disaster of requiring struct page coverage for what
is expected to be ever increasing capacities of persistent memory. In
conversations with Rik van Riel, Mel Gorman, and Jens Axboe at the
Avoid the impending disaster of requiring struct page coverage for what
is expected to be ever increasing capacities of persistent memory. In
conversations with Rik van Riel, Mel Gorman, and Jens Axboe at the
recently concluded Linux Storage Summit it became clear that struct page
is not required
Avoid the impending disaster of requiring struct page coverage for what
is expected to be ever increasing capacities of persistent memory. In
conversations with Rik van Riel, Mel Gorman, and Jens Axboe at the
recently concluded Linux Storage Summit it became clear that struct page
is not required
62 matches
Mail list logo
