Re: uvm vm_physseg trimming

To: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Subject: Re: uvm vm_physseg trimming
From: Cherry G. Mathew <cherry%zyx.in@localhost>
Date: Sat, 09 Jan 2016 22:09:13 +0530
>>>>> "tsutsui" == Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> writes:

    tsutsui> cherry@ wrote:
    >> >>>>> "tsutsui" == Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
    >> writes:
    >> 
    tsutsui> cherry@ wrote:
    >> >> Please find below a patch to remove .avail_(start|end) from >>
    >> struct vm_physseg
    >> 
    tsutsui> What's advantage of these changes?
    >> 
    tsutsui> Changing MD APIs could often cause botches on poor tierII
    tsutsui> ports..
    >> 
    >> On cursory glance, I can't seem to find a port that uses the
    >> avail_start/avail_end members in the way intended by uvm. Instead
    >> they seem to redundantly adjust both .start & .avail_start
    >> (mostly wrt pmap_steal_memory(9) ).
    >> 
    >> I'm implementing an API to dynamically add and remove physical
    >> memory segments at page granularity. Simplifying the api will
    >> make things easier. It's not absolutely essential, but "nice to
    >> have".

    tsutsui> Probably it's better to propose the new API first (even
    tsutsui> without actual code). As per our commit guideline, such
    tsutsui> major API changes require Core's approval.

Please find my proposed API attached.

    tsutsui> IMO, we can still keep the "start" and "end" args in
    tsutsui> uvm_page_physload(9) as dummy to keep API/ABI (to avoid
    tsutsui> extra diffs and possible botches) even after these two
    tsutsui> members will be removed from the struct vm_physseg.

    >> >> I couldn't find a reason for them to be used redundantly, but
    >> I >> may be wrong. Are there port specific uses for these ?
    >> 
    tsutsui> It looks: - start and end are intended to represent
    tsutsui> "existing" memory regions - avail_start and avail_end
    tsutsui> represent free memory regions (to be used by vm) but most
    tsutsui> MD code didn't pass the former ones.
    >> 
    >> Yes, this is what I noticed, and thus the patch.
    >> 
    >> I'd be keen to hear from ports that are affected by this patch.

    tsutsui> I guess currently no ports depend on the physcal start and
    tsutsui> end members.

    tsutsui> I have just remenbered that I wondered if I should handle
    tsutsui> them when I wrote sun3x MACHINE_NEW_NONCONTIG patch and
    tsutsui> worked on news68k port, to handle RAM regions that were
    tsutsui> reserved for PROM monitors.  (IIRC it affected the "total
    tsutsui> memory" value in dmesg)

I *think* we can make semantically well defined uses like the above a
case of adding a new MI property group/ MD property type. Similarly,
"total memory" could be defined to include a bunch of segments which
satisfy a given property filter. Similarly, we could have an MD specific
filter which determines what segments with filtered properties make it
to the free page list.

Comments ?
-- 
Cherry

diff -r 0b3902dbe274 sys/uvm/uvm_physseg.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/sys/uvm/uvm_physseg.h	Sat Jan 09 21:53:07 2016 +0530
@@ -0,0 +1,191 @@
+/* $NetBSD$ */
+
+/*-
+ * Copyright (c) 2015 The NetBSD Foundation, Inc.
+ * All rights reserved.
+ *
+ * This code is derived from software contributed to The NetBSD Foundation
+ * by Cherry G. Mathew
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
+ * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <sys/cdefs.h>
+__RCSID("$NetBSD$");
+
+#include <sys/types.h>
+
+#include <sys/systm.h>
+
+/* Datatypes are usefully exposed only within the module */
+typedef struct uvm_physseg * uvm_physseg_t;
+
+/*
+ * Page Frame Numbers are relevant here because:
+ * i) It avoids alignment issues.
+ * ii) It doesn't assume or imply a PAGE_SIZE value.
+ *
+ * Always use param.h macros to translate pfn_t to paddr_t
+ */
+typedef paddr_t pfn_t;
+
+/*
+ * A physical segment is defined as a stretch of physical address
+ * space, encapsulating certain optional queryable properties.
+ * Properties are categorised into groups.
+ * The following groups are currently defined:
+ *
+ * UVM_PHYSSEG_DMA - DMA accessibility
+ * UVM_PHYSSEG_CPU - cpu affinity
+ * UVM_PHYSSEG_CONTIG - contiguity
+ * UVM_PHYSSEG_PERSIST - persistence
+ *
+ * Note - A property group indicates a specific set of related
+ *	  properties of a segment of memory.
+ *
+ *      - Individual properties *within* groups are considered
+ *	  mutually inclusive, although MD specific exclusions may
+ *	  apply. Note that individual properties are defined in MD
+ *	  code.
+ *
+ *      - Groups without further individual property specifications
+ *	  are considered to have the most inclusive set of
+ *	  properties.
+ *
+ *        For eg: UVM_PHYS_PROP_GROUP_DMA with no further individual
+ *	  constraint will consider the segment to be DMA accessible by
+ *	  any controller on the memory bus.
+ *
+ *        UVM_PHYS_PROP_CPU without further constraint will consider
+ *	  the segment to have equal affinity to all cpus.
+ *	  etc.
+ *
+ *      - A single segment may have multiple properties. These are
+ *	  specified in an array during initialisation of the
+ *	  segment. See: uvm_physseg_init() below.
+ *
+ * All segments lie within the global CPU physical address space.
+ */
+
+enum uvm_physseg_prop_group {
+	/* no special properties. */
+	UVM_PHYSSEG_NONE,
+
+	/* DMA related */
+	UVM_PHYSSEG_DMA,
+
+	/* CPU affinity */
+	UVM_PHYSSEG_CPU,
+
+	/* Contiguity in an MD specified address space */
+	UVM_PHYSSEG_CONTIG,
+
+	/* Persistent memory */
+	UVM_PHYSSEG_PERSIST,
+
+	/*
+	 * Number of property group types - this is not
+	 * a property!
+	 */
+	UVM_PHYSSEG_PROP_COUNT,
+
+	/* Invalid */
+	UVM_PHYSSEG_PROP_INVALID = -1
+};
+
+struct uvm_physseg_prop {
+	const enum uvm_physseg_prop_group group;
+
+	/* This is an opaque object whose details are defined in MD code */
+	const union {
+		const uvm_physseg_dma_t dma;
+		const uvm_physseg_cpu_t cpu;
+		const uvm_physseg_contig_t contig;
+		const uvm_physseg_persist_t persist;
+	} prop;
+};
+
+/*
+ * Segments may be searched using various "strategies" based on the
+ * implementation. Architectures may set strategies at init time.
+ * Strategies are not dynamic - they are set once during boot time.
+ */
+enum uvm_physseg_strat {
+	UVM_PSTRAT_RANDOM,
+	UVM_PSTRAT_BSEARCH,
+	UVM_PSTRAT_BIGFIRST
+};
+
+/* Set global properties */
+void uvm_physseg_set_strat(enum uvm_physseg_strat);
+
+/* Create/Destroy a new segment:
+ * Note: Properties may be passed in in any order.
+ *	Passing in redundant properties is an error.
+ */
+
+uvm_physseg_t uvm_physseg_plug(pfn_t, pfn_t, pfn_t, pfn_t,
+    const struct uvm_physseg_prop [UVM_PHYSSEG_PROP_COUNT]);
+void uvm_physseg_unplug(uvm_physseg_t);
+
+
+/* Ops on existing segment */
+
+/*
+ * A segment update can involve:
+ * Expanding (Prepend/Append) or shrink RAM to an existing segment
+ *           OR
+ * changing its properties.
+ *
+ * Note: Changing the properties of a part of a segment fragments it
+ * into two or three new segments with different properties.
+ *
+ * Similarly, post-expansion coincident segments with matching
+ * properties will be coalesced.
+ *
+ * XXX: Error reporting
+ */
+bool uvm_physseg_update(uvm_physseg_t, pfn_t, pfn_t,
+    const struct uvm_physseg_prop [UVM_PHYSSEG_PROP_COUNT]);
+
+/* Remove parts of a segment, upto page granularity. */
+bool uvm_physseg_delete(uvm_physseg_t, pfn_t, psize_t);
+
+/* Queries on existing segment */
+pfn_t uvm_physseg_start(uvm_physseg_t);
+psize_t uvm_physseg_size(uvm_physseg_t);
+pfn_t uvm_physseg_avail_start(uvm_physseg_t);
+psize_t uvm_physseg_avail_size(uvm_physseg_t);
+
+/*
+ * A valid segment is one which is not yet deleted
+ *                       OR
+ * which has the UVM_PHYSSEG_PROP_INVALID group set.
+ */
+bool uvm_physseg_valid(uvm_physseg_t);
+
+/* Lookup/Traverse segments */
+uvm_physseg_t uvm_physseg_first(void);
+uvm_physseg_t uvm_physseg_last(void);
+uvm_physseg_t uvm_physseg_next(uvm_physseg_t);
+uvm_physseg_t uvm_physseg_prev(uvm_physseg_t);
+uvm_physseg_t uvm_physseg_find(paddr_t);
Follow-Ups:
- Re: uvm vm_physseg trimming
  - From: Cherry G . Mathew
References:
- Re: uvm vm_physseg trimming
  - From: Izumi Tsutsui
Prev by Date: Re: In-kernel process exit hooks?
Next by Date: Re: uvm vm_physseg trimming
Previous by Thread: Re: uvm vm_physseg trimming
Next by Thread: Re: uvm vm_physseg trimming
Indexes:
Home | Main Index | Thread Index | Old Index