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,
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
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
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
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
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
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
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
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
>
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
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
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,
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,
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
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
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
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,
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
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)
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
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
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
Author: nwhitehorn
Date: Sat Jan 13 23:14:53 2018
New Revision: 327950
URL: https://svnweb.freebsd.org/changeset/base/327950
Log:
Document places we assume that physical memory is direct-mapped at zero by
using a new macro PHYS_TO_DMAP, which deliberately has the same name as the
equivalent
28 matches
Mail list logo
