Apex Legends game periodically (every 30 seconds) calls this function
with up to 22k virtual addresses. All but 1 of them is valid. Due to
amount of queries addresses, and cost of seek+read, this causes this
function to take up to about 50ms. So framerate drops from ~150 FPS to
20FPS for about a second.
As far as I can see, returning 0 entries from this function, still makes
Apex Legend work.
But keep code correct, and optimise it by:
1. Opening pagemap file once, and never closing it. This eliminates
repeated fopen/fseek/fread/fclose sequences, which helps even in queries
with small amount of virtual addresses.
2. Using pread, instead of seek+read.
3. Only performing pagemap read when the address is valid.
Future work might recognize continues pages in the query, and perform a
batch read of multiple pagemap entries, instead one page at a time, but
for now it is not necassary.
This change get_working_set_ex peek wall clock runtime from 57ms to
0.29ms.
Tested on Linux, but similar change done for the BSD part.
`Signed-off-by: Witold Baryluk <witold.baryluk(a)gmail.com>`
--
v9: ntdll: Keep pagemap file open after first use of NtQueryVirtualMemory(MemoryWorkingSetExInformation)
ntdll: Use pread in NtQueryVirtualMemory(MemoryWorkingSetExInformation)
ntdll: Do not use hardcoded page shift in NtQueryVirtualMemory(MemoryWorkingSetExInformation)
ntdll: Speed up NtQueryVirtualMemory(MemoryWorkingSetExInformation) by conditional page check
https://gitlab.winehq.org/wine/wine/-/merge_requests/852
On Fri Sep 16 19:50:17 2022 +0000, Etaash Mathamsetty wrote:
> yes I know that, but when I clicked the rebase button the pipeline
> started failing for no reason, now I have to rebase locally which I understand
Yeah I have absolutely no idea why it's failing, it works on my machine with the exact same code
broken pipeline for sure
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/778#note_8735
@zfigura @iamahuman This is my first wine patch, I am not familiar with wine review process, and I am not sure who should review this (bot didn't assign anybody), but I would appreciate a review.
Code should be obvious, but question for the last commit: should I open with `O_CLOEXEC` ? I do not think so, but would be good to confirm.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/852#note_8713
On Fri Sep 16 15:29:32 2022 +0000, Gabriel Ivăncescu wrote:
> It worked properly earlier likely because there were no conflicts. Use
> git locally as normal instead of the web interface to do it.
yes I know that, but when I clicked the rebase button the pipeline started failing for no reason, now I have to rebase locally which I understand
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/778#note_8706
--
v2: ntdll: Fill the IOSB in sock_transmit() only inside the "if (alerted)" block.
ntdll: Fill the IOSB in sock_send() only inside the "if (alerted)" block.
ntdll: Fill the IOSB in sock_recv() only inside the "if (alerted)" block.
ntdll: The async handle passed to set_async_direct_result() cannot be NULL.
ws2_32/tests: Add more tests for iosb contents while a recv is pending.
https://gitlab.winehq.org/wine/wine/-/merge_requests/871
Alternatively, since this is early in startup and we don't expect this malloc()
to fail, we could simply remove the check from get_initial_environment() itself.
--
v2: ntdll: Do not check for malloc() failure in get_initial_environment.
https://gitlab.winehq.org/wine/wine/-/merge_requests/867
--
v2: winegstreamer: Check for already opened stream in wm_reader_open*.
winegstreamer: Use a dedicated CS to serialize async reader commands.
winegstreamer: Introduce a new async_reader_deliver_sample helper.
winegstreamer: Wake thread when async reader user clock is modified.
https://gitlab.winehq.org/wine/wine/-/merge_requests/843
On Fri Sep 16 15:03:29 2022 +0000, Etaash Mathamsetty wrote:
> lol now another issue popped up, the rebase worked properly earlier
> this gitlab is really weird, litterally nothing has worked correctly for me
It worked properly earlier likely because there were no conflicts. Use git locally as normal instead of the web interface to do it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/778#note_8699
On Fri Sep 16 15:28:23 2022 +0000, Huw Davies wrote:
> My Windows SDK has `REG_APP_HIVE` defined to 0x10. It also has
> `REG_PROCESS_PRIVATE` as 0x20, which is presumably what
> `REG_PROCESS_APPKEY` gets mapped to.
> If the tests aren't going to work on Win 7, then skip them as soon as
> the first call returns `STATUS_INVALID_PARAMETER_6`.
> Since you've found that the key return is only available for an app key,
> then I don't think it makes sense to split this MR up as I'd previously
> suggested. That means we need the filename logic back in.
> A couple of notes on that: When passing strings to the server, we
> typically don't nul-terminate them and pass the length instead. Also,
> there is logic there already that copes with loading and saving branches
> i.e. the `save_branch_info` stuff. Have you looked into adapting that?
Oh interesting, where do you find those headers in the windwos sdk? I've tried to find something like that but I'm always afraid of breaking the clean room guidelines.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/820#note_8698
On Thu Sep 15 22:27:44 2022 +0000, Bernhard Kölbl wrote:
> > Rebase failed: Rebase locally, resolve all conflicts, then push the
> branch. Try again.
lol now another issue popped up, the rebase worked properly earlier
this gitlab is really weird, litterally nothing has worked correctly for me
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/778#note_8695