On Sat, 7 Nov 2015, Dan Williams wrote:
> Thanks for that explanation. Peter had alluded to it at KS, but I
> indeed did not know that it was as horrible as milliseconds of
> latency, hmm...
Yes, I was pretty surprised as well. But even if it's just in the
hundreds of microseconds it can be too m
On Sat, Nov 7, 2015 at 12:38 AM, Thomas Gleixner wrote:
> On Sat, 7 Nov 2015, Dan Williams wrote:
>> On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner wrote:
>> > On Fri, 6 Nov 2015, H. Peter Anvin wrote:
>> >> On 11/06/15 15:17, Dan Williams wrote:
>> >> >>
>> >> >> Is it really required to do th
On Sat, 7 Nov 2015, Dan Williams wrote:
> On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner wrote:
> > On Fri, 6 Nov 2015, H. Peter Anvin wrote:
> >> On 11/06/15 15:17, Dan Williams wrote:
> >> >>
> >> >> Is it really required to do that on all cpus?
> >> >
> >> > I believe it is, but I'll double c
On Fri, Nov 6, 2015 at 10:50 PM, Thomas Gleixner wrote:
> On Fri, 6 Nov 2015, H. Peter Anvin wrote:
>> On 11/06/15 15:17, Dan Williams wrote:
>> >>
>> >> Is it really required to do that on all cpus?
>> >
>> > I believe it is, but I'll double check.
>> >
>>
>> It's required on all CPUs on which th
On Fri, 6 Nov 2015, H. Peter Anvin wrote:
> On 11/06/15 15:17, Dan Williams wrote:
> >>
> >> Is it really required to do that on all cpus?
> >
> > I believe it is, but I'll double check.
> >
>
> It's required on all CPUs on which the DAX memory may have been dirtied.
> This is similar to the wa
On 11/06/15 15:17, Dan Williams wrote:
>>
>> Is it really required to do that on all cpus?
>
> I believe it is, but I'll double check.
>
It's required on all CPUs on which the DAX memory may have been dirtied.
This is similar to the way we flush TLBs.
-hpa
--
To unsubscribe from this
On Fri, Nov 6, 2015 at 9:35 AM, Thomas Gleixner wrote:
> On Fri, 6 Nov 2015, Dan Williams wrote:
>> On Fri, Nov 6, 2015 at 12:06 AM, Thomas Gleixner wrote:
>> > Just for the record. Such a flush mechanism with
>> >
>> > on_each_cpu()
>> > wbinvd()
>> > ...
>> >
>> > will make
On November 5, 2015 3:59:46 PM PST, Dan Williams
wrote:
>On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler
> wrote:
>> On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote:
>>> Ross Zwisler writes:
>>>
>>> > This series implements the very slow but correct handling for
>>> > blkdev_issue_flush
On Fri, 6 Nov 2015, Dan Williams wrote:
> On Fri, Nov 6, 2015 at 12:06 AM, Thomas Gleixner wrote:
> > Just for the record. Such a flush mechanism with
> >
> > on_each_cpu()
> > wbinvd()
> > ...
> >
> > will make that stuff completely unusable on Real-Time systems. We've
> > be
On Fri, Nov 6, 2015 at 12:06 AM, Thomas Gleixner wrote:
> On Thu, 5 Nov 2015, Dan Williams wrote:
>> On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler
>> wrote:
>> > On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote:
>> >> Ross Zwisler writes:
>> >>
>> >> > This series implements the very s
On Thu, 5 Nov 2015, Dan Williams wrote:
> On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler
> wrote:
> > On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote:
> >> Ross Zwisler writes:
> >>
> >> > This series implements the very slow but correct handling for
> >> > blkdev_issue_flush() with DAX
On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler
wrote:
> On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote:
>> Ross Zwisler writes:
>>
>> > This series implements the very slow but correct handling for
>> > blkdev_issue_flush() with DAX mappings, as discussed here:
>> >
>> > https://lkml.o
On Thu, Oct 29, 2015 at 7:24 AM, Jeff Moyer wrote:
> Ross Zwisler writes:
>
>> This series implements the very slow but correct handling for
>> blkdev_issue_flush() with DAX mappings, as discussed here:
>>
>> https://lkml.org/lkml/2015/10/26/116
>>
>> I don't think that we can actually do the
>>
On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote:
> Ross Zwisler writes:
>
> > This series implements the very slow but correct handling for
> > blkdev_issue_flush() with DAX mappings, as discussed here:
> >
> > https://lkml.org/lkml/2015/10/26/116
> >
> > I don't think that we can actu
Ross Zwisler writes:
> This series implements the very slow but correct handling for
> blkdev_issue_flush() with DAX mappings, as discussed here:
>
> https://lkml.org/lkml/2015/10/26/116
>
> I don't think that we can actually do the
>
> on_each_cpu(sync_cache, ...);
>
> ...where sync_cache is
This series implements the very slow but correct handling for
blkdev_issue_flush() with DAX mappings, as discussed here:
https://lkml.org/lkml/2015/10/26/116
I don't think that we can actually do the
on_each_cpu(sync_cache, ...);
...where sync_cache is something like:
cache_disable();
16 matches
Mail list logo