Date: Sun, 14 Jan 2018 09:30:53 -0800 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327950 - in head/sys/powerpc: aim include powerpc ps3 Message-ID: <184ba3ee-a9f7-01ed-bb02-1bcba9acc041@freebsd.org> In-Reply-To: <20180114170502.GB1684@kib.kiev.ua> References: <201801132314.w0DNEra5002692@repo.freebsd.org> <20180113232441.GV1684@kib.kiev.ua> <010d0153-8931-a3c2-db21-dfcbaf848fc0@freebsd.org> <f33e9b1a-28bd-e6cf-4bdb-ec0097c0787d@freebsd.org> <20180114083036.GX1684@kib.kiev.ua> <ede06fc6-7c34-100c-8a7a-6346cd8cd363@freebsd.org> <20180114170502.GB1684@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?184ba3ee-a9f7-01ed-bb02-1bcba9acc041>