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.

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

Update and lots of edits #78

Closed
wants to merge 22 commits into from

Conversation

@ilario
Copy link
Member

commented Aug 16, 2019

Here I edited pleeeeenty of things in the website.
Please tell me if I should break the PR in smaller ones.
What is missing is to update the How it works page to describe Babeld instead of BMX6, should I do it or wait for the next release?

@@ -136,5 +163,7 @@ Save and exit
make -j$(nproc)
--------------------------------------------------------------------------------

Where you should replace +$(nproc)+ with the number of _physical_ CPU cores obtainable from +lscpu+ command as _Core(s) per socket_.

This comment has been minimized.

Copy link
@G10h4ck

G10h4ck Aug 20, 2019

Member

$(nproc) return the number of cores presents on the machine no need to do it manually

This comment has been minimized.

Copy link
@ilario

ilario Sep 5, 2019

Author Member

$(nproc) considers all the CPUs also due to hyperthreading, in my experience (with computational stuff just using CPU+RAM and nothing else, not with compilations, which could be different as it uses CPU+RAM+Disk+Network) is noticeably faster to use just as many threads as the physical cores.
I just tested on my laptop with a Intel i7-4600U @ 2.10GHz CPU (Thread(s) per core: 2, Core(s) per socket: 2) using buildroot and doing make clean + make -j#:
using 4 threads it took 14 min 22 s
using 2 threads it took 19 min 45 s
ok, so seems that with the kind of processes involved with OpenWrt compilation, the more processes the better, in the new PR I will remove this comment.

@G10h4ck

This comment has been minimized.

Copy link
Member

commented Aug 20, 2019

To ease the review process it is better to split it in smaller PR

@nicopace

This comment has been minimized.

Copy link
Member

commented Aug 25, 2019

To ease the review process it is better to split it in smaller PR

Would support gio's request, as it is too big to review

@ilario

This comment has been minimized.

Copy link
Member Author

commented Sep 13, 2019

Closing this, I am creating a PR for each of the edited files, I still miss a few.
The content of the new PRs is not just this one broken apart but some further improvements are included.

@ilario

This comment has been minimized.

Copy link
Member Author

commented Sep 15, 2019

All the changes have been ported to new pull requests, please review PR from #79 to #90.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.