On 11/22/2016 11:49 PM, Daniel Vetter wrote:
> Yes, agreed. My idea with exposing vram sections using numa nodes wasn't
> to reuse all the existing allocation policies directly, those won't work.
> So at boot-up your default numa policy would exclude any vram nodes.
>
> But I think (as an -mm laym
On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm
The reason I chose not to do that was that deferred work gets run under
a basically random 'curr
On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in
On 10/11/2016 04:50 PM, Ruchi Kandoi wrote:
> Any process holding a reference to these buffers will keep the kernel from
> reclaiming its backing pages. mm counters don't provide a complete picture of
> these allocations, since they only account for pages that are mapped into a
> process's address
On 03/17/2014 12:49 PM, Jan Kara wrote:
> +int get_vaddr_pfns(unsigned long start, int nr_pfns, int write, int force,
> +struct pinned_pfns *pfns)
> +{
...
> + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
> + pfns->got_ref = 1;
> + pfns->is_pages = 1;
>
On Tue, 2011-10-18 at 10:26 -0700, Michal Nazarewicz wrote:
> > You can do this in a more general fashion by checking the
> > zone boundaries and resolving the pfn->page every MAX_ORDER_NR_PAGES.
> > That will not be SPARSEMEM specific.
>
> I've tried doing stuff that way but it ended up with much
On Wed, 2011-09-21 at 18:26 +0200, Michal Nazarewicz wrote:
> - page += 1 << order;
> +
> + if (zone_pfn_same_memmap(pfn - count, pfn))
> + page += count;
> + else
> + page = pfn_to_page(pfn);
> }
That al
On Wed, 2011-09-21 at 17:19 +0200, Michal Nazarewicz wrote:
> Do the attached changes seem to make sense?
The logic looks OK.
> I wanted to avoid calling pfn_to_page() each time as it seem fairly
> expensive in sparsemem and disctontig modes. At the same time, the
> macro trickery is so that use
On Wed, 2011-09-21 at 15:17 +0200, Michal Nazarewicz wrote:
> > This 'struct page *'++ stuff is OK, but only for small, aligned areas.
> > For at least some of the sparsemem modes (non-VMEMMAP), you could walk
> > off of the end of the section_mem_map[] when you cross a MAX_ORDER
> > boundary. I'd
On Fri, 2011-08-19 at 16:27 +0200, Marek Szyprowski wrote:
> +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long
> end,
> +gfp_t flag)
> +{
> + unsigned long pfn = start, count;
> + struct page *page;
> + struct zone *zone;
> +
On Fri, 2011-04-01 at 00:51 +0200, Michal Nazarewicz wrote:
> On Fri, 01 Apr 2011 00:26:51 +0200, Dave Hansen
> wrote:
> >> Bug in the above place does not mean that we could not allocate
> >> memory. It means caller is broken.
> >
> > Could you explai
On Fri, 2011-04-01 at 00:18 +0200, Michal Nazarewicz wrote:
> On Thu, 31 Mar 2011 23:14:38 +0200, Dave Hansen wrote:
> > We BUG_ON() in bootmem. Basically if we try to allocate an early-boot
> > structure and fail, we're screwed. We can't keep running without an
>
On Thu, 2011-03-31 at 23:09 +0200, Michal Nazarewicz wrote:
> On Thu, 31 Mar 2011 17:58:03 +0200, Dave Hansen
> wrote:
> > On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
> >> +unsigned long alloc_contig_freed_pages(unsigned long start, uns
On Thu, 2011-03-31 at 15:24 -0400, Steven Rostedt wrote:
> On Thu, Mar 31, 2011 at 08:58:03AM -0700, Dave Hansen wrote:
> > On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
> > >
> > > +unsigned long alloc_contig_freed_pages(unsigned long star
if (WARN_ON(++ret >= MAX_ORDER))
> >> + return -EINVAL;
>
> On Thu, 31 Mar 2011 18:02:41 +0200, Dave Hansen wrote:
> > Holy cow, that's dense. Is there really no more straightforward way to
> > do that?
>
> Which part exactly is dense? What would be qual
On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
> + _start = start & (~0UL << ret);
> + _end = alloc_contig_freed_pages(_start, end, flag);
These names are a wee bit lacking. Care to give them proper names that
might let a reader figure out how the "_" makes the variable
On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
> + ret = 0;
> + while (!PageBuddy(pfn_to_page(start & (~0UL << ret
> + if (WARN_ON(++ret >= MAX_ORDER))
> + return -EINVAL;
Holy cow, that's dense. Is there really no more straightforw
On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
>
> +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long
> end,
> + gfp_t flag)
> +{
> + unsigned long pfn = start, count;
> + struct page *page;
> + struct zone
18 matches
Mail list logo
