On Mon, Jul 13, 2015 at 5:57 PM, Peter Zijlstra wrote:
> On Fri, Jul 10, 2015 at 12:26:21PM -0500, Christoph Lameter wrote:
>> On Thu, 9 Jul 2015, Chris Mason wrote:
>>
>> > I think the topic is really interesting and we'll be able to get numbers
>> > from production workloads to help justify and
On Mon, Jul 13, 2015 at 5:57 PM, Peter Zijlstra wrote:
> On Fri, Jul 10, 2015 at 12:26:21PM -0500, Christoph Lameter wrote:
>> On Thu, 9 Jul 2015, Chris Mason wrote:
>>
>> > I think the topic is really interesting and we'll be able to get numbers
>> > from production workloads to help justify and
On Fri, Jul 10, 2015 at 3:09 AM, Chris Mason wrote:
>
> We've started experimenting with these to cut overheads in a few
> critical places, and while we don't have numbers yet I really hope it
> won't take too long.
>
> I think the topic is really interesting and we'll be able to get numbers
>
On Mon, Jul 13, 2015 at 5:57 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jul 10, 2015 at 12:26:21PM -0500, Christoph Lameter wrote:
On Thu, 9 Jul 2015, Chris Mason wrote:
I think the topic is really interesting and we'll be able to get numbers
from production workloads to help
On Fri, Jul 10, 2015 at 3:09 AM, Chris Mason c...@fb.com wrote:
We've started experimenting with these to cut overheads in a few
critical places, and while we don't have numbers yet I really hope it
won't take too long.
I think the topic is really interesting and we'll be able to get
On Mon, Jul 13, 2015 at 5:57 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jul 10, 2015 at 12:26:21PM -0500, Christoph Lameter wrote:
On Thu, 9 Jul 2015, Chris Mason wrote:
I think the topic is really interesting and we'll be able to get numbers
from production workloads to help
On Tue, 14 Jul 2015, Andy Lutomirski wrote:
> Crazy thought: At the risk of proposing something ridiculous, what if
> we had per-cpu memory mappings? We could do this at the cost of up to
> 2kB of memcpy whenever we switch mms. Expensive but maybe not a
> showstopper.
This is not crazy and
On Mon, Jul 13, 2015 at 7:01 AM, Christoph Lameter wrote:
> On Mon, 13 Jul 2015, Peter Zijlstra wrote:
>
>> Now the 'problem' is finding these special regions fast, the easy
>> solution is the same as the one proposed for userspace, one big section.
>> That way the interrupt only has to check if
On Tue, 14 Jul 2015, Andy Lutomirski wrote:
Crazy thought: At the risk of proposing something ridiculous, what if
we had per-cpu memory mappings? We could do this at the cost of up to
2kB of memcpy whenever we switch mms. Expensive but maybe not a
showstopper.
This is not crazy and
On Mon, Jul 13, 2015 at 7:01 AM, Christoph Lameter c...@linux.com wrote:
On Mon, 13 Jul 2015, Peter Zijlstra wrote:
Now the 'problem' is finding these special regions fast, the easy
solution is the same as the one proposed for userspace, one big section.
That way the interrupt only has to
On Mon, 13 Jul 2015, Peter Zijlstra wrote:
> Now the 'problem' is finding these special regions fast, the easy
> solution is the same as the one proposed for userspace, one big section.
> That way the interrupt only has to check if the IP is inside this
> section which is minimal effort.
>
> The
On Fri, Jul 10, 2015 at 12:26:21PM -0500, Christoph Lameter wrote:
> On Thu, 9 Jul 2015, Chris Mason wrote:
>
> > I think the topic is really interesting and we'll be able to get numbers
> > from production workloads to help justify and compare different
> > approaches.
>
> Ok that would be
On Fri, Jul 10, 2015 at 12:26:21PM -0500, Christoph Lameter wrote:
On Thu, 9 Jul 2015, Chris Mason wrote:
I think the topic is really interesting and we'll be able to get numbers
from production workloads to help justify and compare different
approaches.
Ok that would be important. I
On Mon, 13 Jul 2015, Peter Zijlstra wrote:
Now the 'problem' is finding these special regions fast, the easy
solution is the same as the one proposed for userspace, one big section.
That way the interrupt only has to check if the IP is inside this
section which is minimal effort.
The down
On Thu, 9 Jul 2015, Chris Mason wrote:
> I think the topic is really interesting and we'll be able to get numbers
> from production workloads to help justify and compare different
> approaches.
Ok that would be important. I also think that the approach may be used
in kernel to reduce the
On Thu, 9 Jul 2015, Chris Mason wrote:
I think the topic is really interesting and we'll be able to get numbers
from production workloads to help justify and compare different
approaches.
Ok that would be important. I also think that the approach may be used
in kernel to reduce the overhead
On Thu, Jul 09, 2015 at 11:32:45AM -0700, Andy Lutomirski wrote:
> Several people have suggested that Linux should provide users with a
> lightweight mechanism that allows light-weight fancy per-cpu
> operations. This could be used to implement free lists or counters
> without any barriers or
On Thu, Jul 09, 2015 at 11:32:45AM -0700, Andy Lutomirski wrote:
Several people have suggested that Linux should provide users with a
lightweight mechanism that allows light-weight fancy per-cpu
operations. This could be used to implement free lists or counters
without any barriers or atomic
18 matches
Mail list logo
