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
> fr
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 actu
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 t
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 d
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 impor
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 atom
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 operations, for example.
There are at least three approaches floating
10 matches
Mail list logo
