ExtMemObjects...Window vs Actual...

This forum is for general developer support questions.

ExtMemObjects...Window vs Actual...

Postby Belxjander » Sat Sep 09, 2017 9:44 pm

I'm trying to deal with ExtMemObj's that are outside the normal 2GB addressable memory limit while using a limited size window for what is mapped.

If I allocate 64MB or 128MB and decide to use it as a remap window for a beyond 2GB addressable area that is a multiple of the window size (128MB access window into 1GB allocated for example....)

I'm trying to work out if this is even practical within the current mechanisms of the ExecNG Memory Management.

I do know that this will seem somewhat strange but it is required for the way I am currently dealing with non-native ELF and other Executable formats.

locally mapping the allocations is okay so far but when I am dealing with memory locations I can't safely access without a whole window-size=allocation-size I quickly run out of memory before the application proceeds.

I was thinking of an ExtMemObj handle with some means of walking the memory it refers to in window-size steps and accessing things that way.

maybe there is something I'm missing when reading ExtMemObj usage?


I'm trying to workaround DLL loading limitations without introducing too many fake DLLs or loading DLLs recursively until memory is exhausted.
Belxjander
 
Posts: 257
Joined: Mon May 14, 2012 11:26 pm
Location: 日本千葉県松戸市 / Matsudo City, Chiba, Japan

Re: ExtMemObjects...Window vs Actual...

Postby chris » Sun Sep 10, 2017 2:18 pm

You can map parts of extended memory objects. See the documentation for Map() - viewtopic.php?f=26&t=3153#p35042
chris
 
Posts: 548
Joined: Sat Jun 18, 2011 12:05 pm

Re: ExtMemObjects...Window vs Actual...

Postby Belxjander » Mon Sep 11, 2017 5:45 am

chris wrote:You can map parts of extended memory objects. See the documentation for Map() - viewtopic.php?f=26&t=3153#p35042


Well THAT solves my memory virtualization issue with size and location,
I'll just need to deal with resource tracking so many ExtMemObj's (one per object loaded and I will need them ALL sharable)

Now the only limit I have for testing is to get access to a machine with more than 4GB of memory and ExtMemObj support enabled
or to find a PCI card that can provide 4GB or more memory as one of it's functions to slot into my sam440flex to provide the ExtMemObj space to work in.

because I definitely need to stress test with multiple load objects trying to cross-access between virtualizations now
so I can debug the EFFI and XFFI mechanisms (E for Entry and X for Cross-Calling...)

they are sketched into place but definitely require debugging, something still doesn't feel right in that code and that always irrationally irritates me until it is proven stable and working/usable.

But the way map is described certainly makes sense for scatter/gather windowing into IO throughput data,
at least for my first impression, Device drivers can simply allocate a window and then Map each scattered block into a locally contiguous block which is then written as a sequential setup before unmap and release...
If I'm reading that autodoc update right...
as long as all the data is in ExtMemObj memory spaces at least.
Belxjander
 
Posts: 257
Joined: Mon May 14, 2012 11:26 pm
Location: 日本千葉県松戸市 / Matsudo City, Chiba, Japan


Return to General Developer Support

Who is online

Users browsing this forum: No registered users and 2 guests