[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALYGNiNc__rWZGTdW-TZ2zp+HPziCiCj764JECP1tnvK4C0S8A@mail.gmail.com>
Date: Wed, 6 Nov 2013 18:03:39 +0400
From: Konstantin Khlebnikov <koct9i@...il.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Jiri Olsa <jolsa@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Davidlohr Bueso <davidlohr@...com>,
Andrew Morton <akpm@...ux-foundation.org>,
Hugh Dickins <hughd@...gle.com>,
Michel Lespinasse <walken@...gle.com>,
Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...hat.com>,
Guan Xuetao <gxt@...c.pku.edu.cn>, aswin@...com,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mm@...ck.org, Linus Torvalds <torvalds@...ux-foundation.org>,
David Ahern <dsahern@...il.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH] mm: cache largest vma
Some time ago I've thought about caching vma on PTE's struct page.
This will work for all huge vmas not only for largest ones.
Of course this requires some reordering in do_page_fault because
currently it lookups vma before pte for obvious reason.
On Wed, Nov 6, 2013 at 10:01 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Jiri Olsa <jolsa@...hat.com> wrote:
>
>> > But success primarily depends on how useful the tooling UI turns out
>> > to be: create a nice Slang or GTK UI for kprobes and triggers, and/or
>> > turn it into a really intuitive command line UI, and people will use
>> > it.
>> >
>> > I think annotated assembly/source output is a really nice match for
>> > triggers and kprobes, so I'd suggest the Slang TUI route ...
>>
>> yep, current toggling command line UI is not much user friendly
>>
>> but perhaps we should leave it there (because it seems it wont get much
>> better anyway) and focus more on Slang UI as the target one..
>>
>> CCing Arnaldo ;-)
>
> Btw., I think we should do the TUI interface _before_ we can merge the
> kernel changes. Frankly, 'not very user friendly' means that it's not used
> (and tested) much - which begs the question: why merge the feature at all?
>
> Making a new kernel feature usable to as many people as possible must be a
> primary concern, not an afterthought.
>
> Thanks,
>
> Ingo
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists