tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: uvm vm_physseg trimming



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".

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

IMO, we can still keep the "start" and "end" args in uvm_page_physload(9)
as dummy to keep API/ABI (to avoid extra diffs and possible botches)
even after these two 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.

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

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

---
Izumi Tsutsui


Home | Main Index | Thread Index | Old Index