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, Konstantin Belousov wrote:
On Sat, Jan 13, 2018 at 11:14:53PM +0000, 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 recommended; it may also grow an assert that
hw_direct_map
+ * is set.
+ */
+#define PHYS_TO_DMAP(x) x
+#define DMAP_TO_PHYS(x) x
Take a look at the sys/vm/vm_page.c:vm_page_free_prep() function.
I think the checks in there should work as designed, unless I'm
missing something. Am I?
-Nathan
Actually, wait, this is broken if hw_direct_map is not set. I can do an
#ifdef __powerpc__ hack, but do you have opinions for a better MI flag
for "yes, the macro is defined but, no, the direct map may not be
available"?
Exactly. You explicitly noted the need to check for the hw_direct_map
in the comment, so I did not see a need to explain further.
We intended that PHYS_TO_DMAP/DMAP_TO_PHYS become MI KPI. If the symbols
are present, their semantic is the unconditional presence and usability of
the direct map.
sf bufs were rototiled with things like SFBUF_OPTIONAL_DIRECT_MAP, but I
dislike it and hope that PHYS_TO_DMAP would be not damaged this way.
That's unfortunate. Is there any reason you need this to be certain at
compile time? That seems to be quite restrictive and not to add a huge
amount of performance.
We tend to start using PHYS_TO_DMAP in MI code. Both amd64 and arm64 do not
need a qualification.
Given the exciting variety of MMU modes on
PowerPC, there is not any way to guarantee the presence of a direct map
at compile time, so the alternative is to invent a whole new kernel
signalling mechanism for "direct map is almost certainly available, but
might not be", which seems strictly worse, or to have a standard API
that PowerPC can't use, which also seems worse.
Why not use a slight variation of the symbol name, to not confuse MI code ?
E.g. PPC_PHYS_TO_DMAP (only as an example, it is not hard to construct a
better name).
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 optimized out on amd64 and arm64 anyway? I really do not see
the benefit here.
-Nathan
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
