On Fri, 14 Mar 2014 11:05:51 +0800 Li Zefan wrote:
> Hi Davidlohr,
>
> On 2014/3/4 11:26, Linus Torvalds wrote:
> > On Mon, Mar 3, 2014 at 7:13 PM, Davidlohr Bueso wrote:
> >>
> >> Yes, I shortly realized that was silly... but I can say for sure it can
> >> happen and a quick qemu run confirms
Hi Davidlohr,
On 2014/3/4 11:26, Linus Torvalds wrote:
> On Mon, Mar 3, 2014 at 7:13 PM, Davidlohr Bueso wrote:
>>
>> Yes, I shortly realized that was silly... but I can say for sure it can
>> happen and a quick qemu run confirms it. So I see your point as to
>> asking why we need it, so now I'm
On Sun, Mar 9, 2014 at 10:09 AM, Oleg Nesterov wrote:
>
> But it's not the "while we're setting up a new thread", it is "since
> vmacache_valid() was called list time". And the cloning task can just
> sleep(A_LOT) and then do CLONE_VM.
>
> Of course, of course, this race is pute theoretical anyway
On 03/09, Linus Torvalds wrote:
>
> On Sun, Mar 9, 2014 at 5:57 AM, Oleg Nesterov wrote:
> >
> > No, dup_task_struct() is obviously lockless. And the new child is not yet
> > visible to for_each_process_thread().
>
> Ok, then the siimple approach is to just do
>
> /* Did we miss an invalidate
On Sun, Mar 9, 2014 at 5:57 AM, Oleg Nesterov wrote:
>
> No, dup_task_struct() is obviously lockless. And the new child is not yet
> visible to for_each_process_thread().
Ok, then the siimple approach is to just do
/* Did we miss an invalidate event? *
if (mm->seqcount < tsk->seqcount)
On 03/08, Linus Torvalds wrote:
>
> On Sat, Mar 8, 2014 at 11:44 AM, Oleg Nesterov wrote:
> >
> > Sure. But another thread or CLONE_VM task can do vmacache_invalidate(),
> > hit vmacache_seqnum == 0 and call vmacache_flush_all() to solve the
> > problem with potential overflow.
>
> How?
>
> Any in
On Sat, 2014-03-08 at 12:02 -0800, Linus Torvalds wrote:
> On Sat, Mar 8, 2014 at 11:44 AM, Oleg Nesterov wrote:
> >
> > Sure. But another thread or CLONE_VM task can do vmacache_invalidate(),
> > hit vmacache_seqnum == 0 and call vmacache_flush_all() to solve the
> > problem with potential overfl
On Sat, Mar 8, 2014 at 11:44 AM, Oleg Nesterov wrote:
>
> Sure. But another thread or CLONE_VM task can do vmacache_invalidate(),
> hit vmacache_seqnum == 0 and call vmacache_flush_all() to solve the
> problem with potential overflow.
How?
Any invalidation is supposed to hold the mm semaphore fo
looks like I removed lkml somehow, resend...
On 03/08, Linus Torvalds wrote:
>
> On Sat, Mar 8, 2014 at 10:40 AM, Oleg Nesterov wrote:
> >
> > It seems this should be moved into copy_mm(), CLONE_VM needs to invalidate
> > ->vmacache too.
>
> No it doesn't. CLONE_VM doesn't change any of the vma l
On Mon, 03 Mar 2014 16:59:38 -0800 Davidlohr Bueso wrote:
> > > --- a/include/linux/sched.h
> > > +++ b/include/linux/sched.h
> > > @@ -23,6 +23,7 @@ struct sched_param {
> > > #include
> > > #include
> > > #include
> > > +#include
> >
> > This might be awkward - vmacache.h drags in mm.h
On Mon, 2014-03-03 at 19:26 -0800, Linus Torvalds wrote:
> On Mon, Mar 3, 2014 at 7:13 PM, Davidlohr Bueso wrote:
> >
> > Yes, I shortly realized that was silly... but I can say for sure it can
> > happen and a quick qemu run confirms it. So I see your point as to
> > asking why we need it, so now
On Mon, Mar 3, 2014 at 7:13 PM, Davidlohr Bueso wrote:
>
> Yes, I shortly realized that was silly... but I can say for sure it can
> happen and a quick qemu run confirms it. So I see your point as to
> asking why we need it, so now I'm looking for an explanation in the
> code.
We definitely *do*
On Mon, 2014-03-03 at 19:12 -0800, Andrew Morton wrote:
> On Mon, 03 Mar 2014 18:42:33 -0800 Davidlohr Bueso wrote:
>
> > On Mon, 2014-03-03 at 17:23 -0800, Andrew Morton wrote:
> > > On Mon, 03 Mar 2014 16:59:38 -0800 Davidlohr Bueso
> > > wrote:
> > >
> > > > > >...
> > > > > >
> > > > > > +
On Mon, 2014-03-03 at 17:23 -0800, Andrew Morton wrote:
> On Mon, 03 Mar 2014 16:59:38 -0800 Davidlohr Bueso wrote:
>
> > > >...
> > > >
> > > > +static bool vmacache_valid(struct mm_struct *mm)
> > > > +{
> > > > + struct task_struct *curr = current;
> > > > +
> > > > + if (mm != cur
On Mon, 2014-03-03 at 16:40 -0800, Andrew Morton wrote:
> On Thu, 27 Feb 2014 13:48:24 -0800 Davidlohr Bueso wrote:
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -342,9 +342,9 @@ struct mm_rss_stat {
> >
> > struct kioctx_table;
> > struct mm_struct {
> > - str
On Mon, 2014-03-03 at 16:00 -0800, Andrew Morton wrote:
> On Thu, 27 Feb 2014 13:48:24 -0800 Davidlohr Bueso wrote:
>
> > From: Davidlohr Bueso
> >
> > This patch is a continuation of efforts trying to optimize find_vma(),
> > avoiding potentially expensive rbtree walks to locate a vma upon fau
On Thu, 2014-02-27 at 13:48 -0800, Davidlohr Bueso wrote:
> From: Davidlohr Bueso
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 8740213..95c2bd9 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -768,16 +768,23 @@ static void add_vma_to_mm(struct mm_struct *mm, struct
> vm_area_struct *vma)
>
From: Davidlohr Bueso
This patch is a continuation of efforts trying to optimize find_vma(),
avoiding potentially expensive rbtree walks to locate a vma upon faults.
The original approach (https://lkml.org/lkml/2013/11/1/410), where the
largest vma was also cached, ended up being too specific and
18 matches
Mail list logo
