On Wed, 2020-02-05 at 14:12 +, David Woodhouse wrote:
> I think we have a viable path to fixing that, by folding PGC_broken in to
> the state bits so that we can disambiguate. Will experiment.
Here, it looks something like this. First we fold PGC_broken into the
state bits giving us 8 possible
> On 05.02.2020 12:23, David Woodhouse wrote:
>> On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
>>> Yet, as you say elsewhere, whether an MFN has an
>>> entry in frame_table[] is entirely unclear, so permitting boot-
>>> allocator pages to be freed via alloc_domheap_pages() nevertheless
>>
On 05.02.2020 12:23, David Woodhouse wrote:
> On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
>> Yet, as you say elsewhere, whether an MFN has an
>> entry in frame_table[] is entirely unclear, so permitting boot-
>> allocator pages to be freed via alloc_domheap_pages() nevertheless
>> still d
On Wed, 2020-02-05 at 10:22 +, Julien Grall wrote:
> However, I don't like the idea of relying on count_info == 0. Indeed,
> there are valid case where count_info == 0 because it means the page is
> inuse (PCC_state_inuse).
>
> It might be best if we introduce a new page state that would be
On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
> Yet, as you say elsewhere, whether an MFN has an
> entry in frame_table[] is entirely unclear, so permitting boot-
> allocator pages to be freed via alloc_domheap_pages() nevertheless
> still doesn't look any better an idea to me.
Hm, I don't
On 05.02.2020 11:24, David Woodhouse wrote:
> On Wed, 2020-02-05 at 11:02 +0100, Jan Beulich wrote:
>>> +/* Pages from the boot allocator need to pass through
>>> init_heap_pages() */
>>> +if ( unlikely(!pg->count_info) )
>>
>> ... while I think this check may be fine here, no similar one
On Wed, 2020-02-05 at 10:22 +, Julien Grall wrote:
> Hi,
>
> On 05/02/2020 09:50, David Woodhouse wrote:
> > On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
> > > At very least it's more robust this way; the algorithm is also less
> > > "magic". We just had a long discussion this morn
On Wed, 2020-02-05 at 11:02 +0100, Jan Beulich wrote:
> > +/* Pages from the boot allocator need to pass through
> > init_heap_pages() */
> > +if ( unlikely(!pg->count_info) )
>
> ... while I think this check may be fine here, no similar one
> can be used in free_domheap_pages(), yet page
Hi,
On 05/02/2020 09:50, David Woodhouse wrote:
On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
At very least it's more robust this way; the algorithm is also less
"magic". We just had a long discussion this morning trying to re-create
the logic for why "Remove MFN 0" was sufficient to
On 05.02.2020 10:50, David Woodhouse wrote:
> On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
>> At very least it's more robust this way; the algorithm is also less
>> "magic". We just had a long discussion this morning trying to re-create
>> the logic for why "Remove MFN 0" was sufficient
On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
> At very least it's more robust this way; the algorithm is also less
> "magic". We just had a long discussion this morning trying to re-create
> the logic for why "Remove MFN 0" was sufficient to prevent this issue,
> and even then David was
On Tuesday, February 4, 2020 10:22 AM, Jan Beulich wrote:
>On 04.02.2020 16:14, Stewart Hildebrand wrote:
>> From: Jeff Kubascik
>>
>> The Xen heap is split up into nodes and zones. Each node + zone is
>> managed as a separate pool of memory.
>>
>> When returning pages to the heap, free_heap_pages
On 2/4/20 3:22 PM, Jan Beulich wrote:
> On 04.02.2020 16:14, Stewart Hildebrand wrote:
>> From: Jeff Kubascik
>>
>> The Xen heap is split up into nodes and zones. Each node + zone is
>> managed as a separate pool of memory.
>>
>> When returning pages to the heap, free_heap_pages will check adjacen
On 04.02.2020 16:14, Stewart Hildebrand wrote:
> From: Jeff Kubascik
>
> The Xen heap is split up into nodes and zones. Each node + zone is
> managed as a separate pool of memory.
>
> When returning pages to the heap, free_heap_pages will check adjacent
> blocks to see if they can be combined in
From: Jeff Kubascik
The Xen heap is split up into nodes and zones. Each node + zone is
managed as a separate pool of memory.
When returning pages to the heap, free_heap_pages will check adjacent
blocks to see if they can be combined into a larger block. However, the
zone of the adjacent block is
15 matches
Mail list logo
