Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

memory size isn't reported to application #2

Closed
convolvatron opened this issue Jan 4, 2018 · 1 comment
Closed

memory size isn't reported to application #2

convolvatron opened this issue Jan 4, 2018 · 1 comment

Comments

@convolvatron
Copy link
Contributor

we look for the e820 region, but don't try to pass it to the user. it contains several segments, the most important being the ~4G before the 'pci gap' and what should be flat memory afterwards.

we could most likely move everything out of the pci gap, but we'd have to adjust the mtrrs and its really not worth it.

so add multi-segement reporting, and look at the 64 bit e820 extensions...or* maybe the virtio balloon interface lets just get the initial memory status - that would be a lot cleaner
@convolvatron
Copy link
Contributor Author

stage1.s pushes these e820 descriptors underneath the entries table, parsing them in stage2, they track the -m allocation passed to qmeu

@convolvatron convolvatron mentioned this issue Aug 24, 2018
Closed
@wjhun wjhun mentioned this issue Sep 6, 2018
Closed
This was referenced Sep 22, 2018
Closed
Closed
@tijoytom-zz tijoytom-zz mentioned this issue Nov 1, 2018
Closed
@mkhon mkhon mentioned this issue Feb 22, 2019
Closed
@wjhun wjhun mentioned this issue Mar 8, 2019
Closed
francescolavra added a commit that referenced this issue May 21, 2021
@francescolavra
lwIP performance optimization
dee60b1 
This commit changes a few lwIP configuration options, following the
hints at https://www.nongnu.org/lwip/2_1_x/optimization.html.
The lwip_htons() and lwip_htonl() macros have been defined so that
byte order inversion operations are executed inline instead of as
function calls (in #1299, the lwip_htons() function shows up as
taking a non-negligible share of CPU time).
Instead of the default checksum algorithm #2, algorithm #3 is now
being used, because it is faster on 64-bit platforms (checksum
calculation on 20-byte data is around 35% faster).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@convolvatron