[Question] Dll library cpu usage about pcileech

[ufrisk]

If you read as frequently as possible the CPU usage is going to be high. One thread will be doing PCILeech work all the time, and this is not a problem if your computer have more than CPU core.

If reading a very small value as frequently as possible I would recommend using the VMM_FLAG_NOCACHE - the last thing you want is to have your value cached for a couple of seconds before it's refreshed.

PCILeech_VmmReadEx(dwPID, vaAddressToRead, pb, cb, &cbRead, VMM_FLAG_NOCACHE);

Also there is a small delay when reading from the FPGA of of approx: 500uS which is waited in a loop (consumes a lot of cpu). The reason for this is that there is no Sleep function in Windows that will sleep the thread this short amount of time.

If you wish to tune that wait period you can do so by setting the values as per below

PCILeech_DeviceConfigSet(PCILEECH_DEVICE_OPT_FPGA_DELAY_READ, <yourvalue>);
PCILeech_DeviceConfigSet(PCILEECH_DEVICE_OPT_FPGA_DELAY_WRITE, <yourvalue>);

Please note that setting very low values may result in insability and errors. But they are very conservatively set from the beginning. If reading very small amounts of memory it may even be possible to set it to zero, but you have to try it out on your system.

[hrt]

Are you sure it is the mem read function?
I haven't used the DLL myself but having loops without any kind of sleep will use large % of CPU regardless of what you do.

[false]

Well, yes, my cpu usage focuses on these read calls. I managed to optimize them a bit by reading big chunks at a time then access directly the elements through memory. But it's still not perfect.
I think I can do something with the cache options though. I am currently testing if I can get something quite good out of the option "PCILEECH_VMM_CONFIG_READCACHE_TICKS" .

[hrt]

Pretty sure there's a good reason there are some delays (hoping someone will tell me why) but I changed the config:
DELAY_READ to 0 in (for me) devicefpga.c
code runs about 3 times faster.
I've also tried caching virtual to physical mappings myself (I'm not using the dll) but surprisingly it was more of a performance hit than boost.
Might re-try the caching though

[hrt]

update : caching efficiently further cut my speed by a factor of at least 6
I'm doing quite a lot of reads in 20ms using pciescreamer

but there are less error checks (cache is made to refresh the mapping for that virtual address every 2000 times it is accessed) -> room for error

[hrt]

QWORD VirtualToPhysical(_Inout_ PPCILEECH_CONTEXT ctx, QWORD virtualAddress)
{
  QWORD pageBase, pageSize;
  DWORD offset = virtualAddress % CACHE_SIZE;
  if (!cache[offset].physicalAddress | cache[offset].hits > RETRY_COUNT | !cache[offset].result)
  {
    cache[offset].result = Util_PageTable_Virtual2Physical(ctx, ctx->cfg->qwCR3, virtualAddress, &(cache[offset].physicalAddress), &pageBase, &pageSize);
    cache[offset].physicalAddress *= cache[offset].result; 
  }
  cache[offset].hits += 1;
  return cache[offset].physicalAddress;
}

I'm not sure how this all goes into play with the dll because I haven't touched/looked at it

[false]

Yes, PCILeech_DeviceConfigSet(PCILEECH_DEVICE_OPT_FPGA_DELAY_READ, 1); fixed my problem to be honnest ; Or at least I can't notice any kind of bad performance anymore.

On the same kind of subject, I have noticed a big usage of memory by pcileech. Is that because you cache everything ? I did not have the time to check sources about it yet.
I have about 150MB referenced under pcileech.dll in my application memory usage.
Is that normal ? Anyway to optimize it as I don't use the pcileech cache at all ?

[ufrisk]

If you initialize the VMM the cache will always be created. This takes up quite some memory. Even if you do not use the read cache you'll use the page table cache and process cache.

But is this super important? 150MB may be big but it's not huge; and computers usually have gigabytes of memory these days ...

[false]

No it is not an issue at all indeed. I just wanted to make sure it was the normal behavior, not a leak or anything. Ty