Adam Litke wrote on Monday, August 08, 2005 3:17 PM
> The reason for the VM_FAULT_SIGBUS default return is because I thought a
> fault on a pte_present hugetlb page was an invalid/unhandled fault.
> I'll have another think about races to the fault handler though.
Two threads fault on the same pte
On Fri, 2005-08-05 at 17:05, Chen, Kenneth W wrote:
> Adam Litke wrote on Friday, August 05, 2005 8:22 AM
> > Below is a patch to implement demand faulting for huge pages. The main
> > motivation for changing from prefaulting to demand faulting is so that
> > huge page allocations can follow the N
Adam Litke wrote on Friday, August 05, 2005 8:22 AM
> Below is a patch to implement demand faulting for huge pages. The main
> motivation for changing from prefaulting to demand faulting is so that
> huge page allocations can follow the NUMA API. Currently, huge pages
> are allocated round-robin
On Fri, Aug 05, 2005 at 02:05:42PM -0700, Chen, Kenneth W wrote:
> Adam Litke wrote on Friday, August 05, 2005 8:22 AM
> > Below is a patch to implement demand faulting for huge pages. The main
> > motivation for changing from prefaulting to demand faulting is so that
> > huge page allocations can
Adam Litke wrote on Friday, August 05, 2005 8:22 AM
> +int hugetlb_pte_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> + unsigned long address, int write_access)
> +{
> + int ret = VM_FAULT_MINOR;
> + unsigned long idx;
> + pte_t *pte;
> + struct page *
Adam Litke wrote on Friday, August 05, 2005 8:22 AM
> Below is a patch to implement demand faulting for huge pages. The main
> motivation for changing from prefaulting to demand faulting is so that
> huge page allocations can follow the NUMA API. Currently, huge pages
> are allocated round-robin
On Fri, Aug 05, 2005 at 12:00:00PM -0500, Adam Litke wrote:
> On Fri, 2005-08-05 at 11:47, Andi Kleen wrote:
> > On Fri, Aug 05, 2005 at 11:37:27AM -0500, Adam Litke wrote:
> > > On Fri, 2005-08-05 at 10:53, Andi Kleen wrote:
> > > > On Fri, Aug 05, 2005 at 10:21:38AM -0500, Adam Litke wrote:
> > >
On Fri, 5 Aug 2005, Andi Kleen wrote:
> > Unless I am missing something, the call to follow_hugetlb_page() in
> > get_user_pages() is just an optimization. Removing it means
> > follow_page() will be called individually for each PAGE_SIZE page in the
> > huge page. We can probably do better but
On Fri, 2005-08-05 at 11:47, Andi Kleen wrote:
> On Fri, Aug 05, 2005 at 11:37:27AM -0500, Adam Litke wrote:
> > On Fri, 2005-08-05 at 10:53, Andi Kleen wrote:
> > > On Fri, Aug 05, 2005 at 10:21:38AM -0500, Adam Litke wrote:
> > > > Below is a patch to implement demand faulting for huge pages. Th
On Fri, Aug 05, 2005 at 11:37:27AM -0500, Adam Litke wrote:
> On Fri, 2005-08-05 at 10:53, Andi Kleen wrote:
> > On Fri, Aug 05, 2005 at 10:21:38AM -0500, Adam Litke wrote:
> > > Below is a patch to implement demand faulting for huge pages. The main
> > > motivation for changing from prefaulting t
On Fri, 2005-08-05 at 10:53, Andi Kleen wrote:
> On Fri, Aug 05, 2005 at 10:21:38AM -0500, Adam Litke wrote:
> > Below is a patch to implement demand faulting for huge pages. The main
> > motivation for changing from prefaulting to demand faulting is so that
> > huge page allocations can follow th
On Fri, Aug 05, 2005 at 10:21:38AM -0500, Adam Litke wrote:
> Below is a patch to implement demand faulting for huge pages. The main
> motivation for changing from prefaulting to demand faulting is so that
> huge page allocations can follow the NUMA API. Currently, huge pages
> are allocated roun
12 matches
Mail list logo
