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 changin
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 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 long
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 som
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 a
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 su
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 whi
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, an
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 s
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% p
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
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 wou
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 additi
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 s
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 persisten
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 wit
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 Linu
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 beli
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
> "anoth
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
21 matches
Mail list logo
