On 01/18/2018 09:35, Konstantin Belousov wrote:
> On Thu, Jan 18, 2018 at 07:24:11AM -0800, Nathan Whitehorn wrote:
>>
>> On 01/17/18 01:44, Konstantin Belousov wrote:
>>> On Tue, Jan 16, 2018 at 09:30:29PM -0800, Nathan Whitehorn wrote:
On 01/16/18 11:32, Marius Strobl wrote:
> On Mon, Ja
On 01/18/18 07:35, Konstantin Belousov wrote:
On Thu, Jan 18, 2018 at 07:24:11AM -0800, Nathan Whitehorn wrote:
On 01/17/18 01:44, Konstantin Belousov wrote:
On Tue, Jan 16, 2018 at 09:30:29PM -0800, Nathan Whitehorn wrote:
On 01/16/18 11:32, Marius Strobl wrote:
On Mon, Jan 15, 2018 at 03
On Thu, Jan 18, 2018 at 07:24:11AM -0800, Nathan Whitehorn wrote:
>
>
> On 01/17/18 01:44, Konstantin Belousov wrote:
> > On Tue, Jan 16, 2018 at 09:30:29PM -0800, Nathan Whitehorn wrote:
> >>
> >> On 01/16/18 11:32, Marius Strobl wrote:
> >>> On Mon, Jan 15, 2018 at 03:20:49PM -0800, Nathan Whit
On 01/17/18 01:44, Konstantin Belousov wrote:
On Tue, Jan 16, 2018 at 09:30:29PM -0800, Nathan Whitehorn wrote:
On 01/16/18 11:32, Marius Strobl wrote:
On Mon, Jan 15, 2018 at 03:20:49PM -0800, Nathan Whitehorn wrote:
On 01/15/18 09:53, Konstantin Belousov wrote:
On Mon, Jan 15, 2018 at 09
On Tue, Jan 16, 2018 at 09:30:29PM -0800, Nathan Whitehorn wrote:
>
>
> On 01/16/18 11:32, Marius Strobl wrote:
> > On Mon, Jan 15, 2018 at 03:20:49PM -0800, Nathan Whitehorn wrote:
> >>
> >> On 01/15/18 09:53, Konstantin Belousov wrote:
> >>> On Mon, Jan 15, 2018 at 09:32:56AM -0800, Nathan Whit
On 01/16/18 11:32, Marius Strobl wrote:
On Mon, Jan 15, 2018 at 03:20:49PM -0800, Nathan Whitehorn wrote:
On 01/15/18 09:53, Konstantin Belousov wrote:
On Mon, Jan 15, 2018 at 09:32:56AM -0800, Nathan Whitehorn wrote:
That seems fine to me. I don't think a less-clumsy way that does not
invo
On Mon, Jan 15, 2018 at 03:20:49PM -0800, Nathan Whitehorn wrote:
>
>
> On 01/15/18 09:53, Konstantin Belousov wrote:
> > On Mon, Jan 15, 2018 at 09:32:56AM -0800, Nathan Whitehorn wrote:
> >> That seems fine to me. I don't think a less-clumsy way that does not
> >> involve extra indirection is p
On 01/15/2018 20:40, Nathan Whitehorn wrote:
>
>
> On 01/15/18 15:42, Konstantin Belousov wrote:
>> On Mon, Jan 15, 2018 at 03:20:49PM -0800, Nathan Whitehorn wrote:
>>> Fair enough. Here's a patch with a new flag (DIRECT_MAP_AVAILABLE).
>>> I've
>>> also retooled the sfbuf code to use this rather
On 01/15/18 15:42, Konstantin Belousov wrote:
On Mon, Jan 15, 2018 at 03:20:49PM -0800, Nathan Whitehorn wrote:
Fair enough. Here's a patch with a new flag (DIRECT_MAP_AVAILABLE). I've
also retooled the sfbuf code to use this rather than its own flags that
mean the same things. The sparc64 par
On Mon, Jan 15, 2018 at 03:20:49PM -0800, Nathan Whitehorn wrote:
> Fair enough. Here's a patch with a new flag (DIRECT_MAP_AVAILABLE). I've
> also retooled the sfbuf code to use this rather than its own flags that
> mean the same things. The sparc64 part of the patch is untested.
> -Nathan
> In
On 01/15/18 09:53, Konstantin Belousov wrote:
On Mon, Jan 15, 2018 at 09:32:56AM -0800, Nathan Whitehorn wrote:
That seems fine to me. I don't think a less-clumsy way that does not
involve extra indirection is possible. The PHYS_TO_DMAP() returning NULL
is about the best thing I can come up wi
On Mon, Jan 15, 2018 at 09:32:56AM -0800, Nathan Whitehorn wrote:
> That seems fine to me. I don't think a less-clumsy way that does not
> involve extra indirection is possible. The PHYS_TO_DMAP() returning NULL
> is about the best thing I can come up with from a clumsiness standpoint
> since pl
On 01/15/18 09:06, Konstantin Belousov wrote:
On Mon, Jan 15, 2018 at 07:33:01AM -0800, Nathan Whitehorn wrote:
On 01/15/18 03:18, Konstantin Belousov wrote:
On Sun, Jan 14, 2018 at 03:46:38PM -0800, Nathan Whitehorn wrote:
On 01/14/18 15:42, Nathan Whitehorn wrote:
On 01/14/18 09:57, Nath
On Mon, Jan 15, 2018 at 07:33:01AM -0800, Nathan Whitehorn wrote:
>
>
> On 01/15/18 03:18, Konstantin Belousov wrote:
> > On Sun, Jan 14, 2018 at 03:46:38PM -0800, Nathan Whitehorn wrote:
> >>
> >> On 01/14/18 15:42, Nathan Whitehorn wrote:
> >>>
> >>> On 01/14/18 09:57, Nathan Whitehorn wrote:
>
On 01/15/18 03:18, Konstantin Belousov wrote:
On Sun, Jan 14, 2018 at 03:46:38PM -0800, Nathan Whitehorn wrote:
On 01/14/18 15:42, Nathan Whitehorn wrote:
On 01/14/18 09:57, Nathan Whitehorn wrote:
On 01/14/18 09:52, Konstantin Belousov wrote:
On Sun, Jan 14, 2018 at 09:30:53AM -0800, Na
On Sun, Jan 14, 2018 at 03:46:38PM -0800, Nathan Whitehorn wrote:
>
>
> On 01/14/18 15:42, Nathan Whitehorn wrote:
> >
> >
> > On 01/14/18 09:57, Nathan Whitehorn wrote:
> >>
> >>
> >> On 01/14/18 09:52, Konstantin Belousov wrote:
> >>> On Sun, Jan 14, 2018 at 09:30:53AM -0800, Nathan Whitehorn w
On 01/14/18 15:42, Nathan Whitehorn wrote:
On 01/14/18 09:57, Nathan Whitehorn wrote:
On 01/14/18 09:52, Konstantin Belousov wrote:
On Sun, Jan 14, 2018 at 09:30:53AM -0800, Nathan Whitehorn wrote:
The immediate consequence of that is that no MI code that knows about
direct maps can poss
On 01/14/18 09:57, Nathan Whitehorn wrote:
On 01/14/18 09:52, Konstantin Belousov wrote:
On Sun, Jan 14, 2018 at 09:30:53AM -0800, Nathan Whitehorn wrote:
The immediate consequence of that is that no MI code that knows about
direct maps can possibly take advantage of the direct map on this
On 01/14/18 09:52, Konstantin Belousov wrote:
On Sun, Jan 14, 2018 at 09:30:53AM -0800, Nathan Whitehorn wrote:
The immediate consequence of that is that no MI code that knows about
direct maps can possibly take advantage of the direct map on this
platform. Do we really want that to save some
On Sun, Jan 14, 2018 at 09:30:53AM -0800, Nathan Whitehorn wrote:
> The immediate consequence of that is that no MI code that knows about
> direct maps can possibly take advantage of the direct map on this
> platform. Do we really want that to save some conditional logic that
> would get optimiz
On 01/14/18 09:05, Konstantin Belousov wrote:
On Sun, Jan 14, 2018 at 08:06:19AM -0800, Nathan Whitehorn wrote:
On 01/14/18 00:30, Konstantin Belousov wrote:
On Sat, Jan 13, 2018 at 08:31:40PM -0800, Nathan Whitehorn wrote:
On 01/13/18 15:28, Nathan Whitehorn wrote:
On 01/13/18 15:24, Kons
On Sun, Jan 14, 2018 at 08:06:19AM -0800, Nathan Whitehorn wrote:
>
>
> On 01/14/18 00:30, Konstantin Belousov wrote:
> > On Sat, Jan 13, 2018 at 08:31:40PM -0800, Nathan Whitehorn wrote:
> >>
> >> On 01/13/18 15:28, Nathan Whitehorn wrote:
> >>>
> >>> On 01/13/18 15:24, Konstantin Belousov wrote
On 01/14/18 00:30, Konstantin Belousov wrote:
On Sat, Jan 13, 2018 at 08:31:40PM -0800, Nathan Whitehorn wrote:
On 01/13/18 15:28, Nathan Whitehorn wrote:
On 01/13/18 15:24, Konstantin Belousov wrote:
On Sat, Jan 13, 2018 at 11:14:53PM +, Nathan Whitehorn wrote:
+/*
+ * We (usually) h
On Sat, Jan 13, 2018 at 08:31:40PM -0800, Nathan Whitehorn wrote:
>
>
> On 01/13/18 15:28, Nathan Whitehorn wrote:
> >
> >
> > On 01/13/18 15:24, Konstantin Belousov wrote:
> >> On Sat, Jan 13, 2018 at 11:14:53PM +, Nathan Whitehorn wrote:
> >>> +/*
> >>> + * We (usually) have a direct map of
On 01/13/18 15:28, Nathan Whitehorn wrote:
On 01/13/18 15:24, Konstantin Belousov wrote:
On Sat, Jan 13, 2018 at 11:14:53PM +, Nathan Whitehorn wrote:
+/*
+ * We (usually) have a direct map of all physical memory. All
+ * uses of this macro must be gated by a check on hw_direct_map!
+ *
On 01/13/18 15:24, Konstantin Belousov wrote:
On Sat, Jan 13, 2018 at 11:14:53PM +, Nathan Whitehorn wrote:
+/*
+ * We (usually) have a direct map of all physical memory. All
+ * uses of this macro must be gated by a check on hw_direct_map!
+ * The location of the direct map may not be 1:1
On Sat, Jan 13, 2018 at 11:14:53PM +, Nathan Whitehorn wrote:
> +/*
> + * We (usually) have a direct map of all physical memory. All
> + * uses of this macro must be gated by a check on hw_direct_map!
> + * The location of the direct map may not be 1:1 in future, so use
> + * of the macro is re
27 matches
Mail list logo
