Προς το περιεχόμενο

ΕΛ/ΛΑΚ: Επικαιρότητα - Τελευταία Νέα


DIMITRISG

Προτεινόμενες αναρτήσεις

Kubuntu - baloo - ionice - default scheduler


Σύνοψη
Το Kubuntu μπορεί να γίνει προβληματικό και αργό σε μηχανικούς σκληρούς δίσκους.

Ο Λόγος
Ο default I/O sceduler που χρησιμοποιεί το Ubuntu είναι ο deadline, ο οποίος δεν υποστηρίζει την ionice. Εν αντιθέσει με τον CFQ που είναι ο default upstream kernel scheduler. To baloo που χρησιμοποιείται πλέον από default στο Kubuntu(KDE), χρειάζεται την ionice για να δουλέψει σωστά και χωρίς κολλήματα.
To Ubuntu, μιας και διατηρεί την δική του ομάδα πυρήνα(Ubuntu Kernel Team) αλλάζει τον default scheduler downstream σε deadline, γιατί τους εξυπηρετεί καλύτερα με το Unity και τo Zeitgeist.

Η Λύση
Φυσικά αυτό επηρεάζει μόνον όσους/ες χρησιμοποιούν Kubuntu (Ubuntu με KDE δηλαδή) ή κάποια Ubuntu-based έκδοση(με KDE).
Η λύση που προτείνουν (οι του Kubuntu) είναι ένα udev rule που θα αλλάζει (μόνο στο Kubuntu) τον default scheduler σε CFQ.

Το workaround
Ανεξαρτήτως αν θα προχωρήσουν ή όχι στην συγκεκριμένη λύση, μπορεί κάποιος να αλλάξει μόνιμα τον I/O scheduler κάνοντας μια επεξεργασία στο αρχείο /etc/default/grub και προσθέτοντας την παράμετρο elevator=cfq στην γραμμή GRUB_CMDLINE_LINUX_DEFAULT (εκεί που βρίσκεται το quite και το splash). Για να περάσει η αλλαγή τρέχουμε αμέσως μετά: sudo update-grub

Πως βλέπω τον default scheduler;
Σε τερματικό δίνουμε

cat /sys/block/sda/queue/scheduler
Αυτός που βρίσκεται μέσα στις αγκύλες, είναι αυτός που χρησιμοποιείται.
Η πηγή
https://lists.ubuntu.com/archives/ubuntu-release/2014-October/003054.html
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

  • Απαντ. 3,9k
  • Δημ.
  • Τελ. απάντηση

Συχνή συμμετοχή στο θέμα

Και η απάντηση από έναν Kernel Developer 

 

Πηγή εδώ

και παράθεση στο spoiler

 

 

 
Someone pointed me to Lennart Poettering's post. I had to read it offline from Google+ because Lennart has blocked me.

https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/J2TZrTvu7vd

From what I gather, there's lots of reshare's of this, but again, I wouldn't know as I'm blocked, and I don't see it even if people who did not block me reshare it.

I'll share some of my thoughts about it here. First, I have to think I'm one of the ones he mentions here:

"(But it is not just Linus, it's a certain group of people around him who use the exact same style, some of which semi-publically even phantasize about the best ways to, ... well, kill me)"

I mean, I'm a kernel developer which works with Linus, and I'm blocked by Lennart.

I will say though, that I have never publicly, semi-publicly, or even privately, threaten personal harm on Lennart. I've drank beers with the guy, and have nothing personal against him.

Now why did he block me? I have no idea, as I don't post on his wall. He blocked me shortly after I posted the infamous "debug" patch that hid the debug command line when things were not being solved on the systemd bugzilla. Or maybe he blocked me after I posted some rants I had with systemd that was making my life hard. When I found out he blocked me, it proved my point that he's not a good leader of a project as he does not take well to criticism and thus will not learn.

This is the first time I've heard about the death threats he has been receiving. Nobody deserves such threats. The internet is filled with such vile low lifes. I condemn all such threats. This is not an open source problem, it is much bigger than that. It's due to the openness of the internet itself, and the anonymous nature of it as well. Any shithead can post crap with very little risk of being exposed. This can happen to any public figure, whether it's in the open source community, entertainment, or politics. Not much can be done to stop it.

The issue I have with Lennart's post is, how dare he point the blame to Linus Torvalds?  Linus is very good at collaborating. He doesn't block people that post criticisms about his products. Do not blame the actions of these bottom feeders to the criticism Linus has made to you and Kay. Lennart, you are the one that refuses to collaborate.

SysV init needed a replacement. And systemd can be that and much more. But your refusal to help make the transition easier, I consider laziness. You don't want to be bothered with a method of handling no cgroups. Debian's systemd-shim interface is filled with bugs (you're not directly responsible for that, but I blame you for its design). You do come across as arrogant and the my-way-or-the-highway approach is what is pissing so many people off. One thing I've learned from working in Open Source community for the last 16 years, is that people that say they know better than everyone else are the ones that are not treated well by the community. But those that are willing to collaborate, and listen to others before pushing their own methods are welcomed with open arms.

Again, you do not deserve the threats, and I truly do feel bad that you received them, but before you go and blame Linus and others for them, take a look in the mirror. The internet is like a bee hive. There's lots of sweet honey there for you, but if you just barge right in to grab it, you might get stung.

  • Like 1
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Με μια λέξη: ουάου!!!!

Δεν περίμενα ότι τα πράγματα θα έφταναν τόσο γρήγορα εκεί. Βέβαια καλύτερα τώρα παρά μετά από 1-2 χρόνια. Να δούμε και το αποτέλεσμα της ψηφοφορίας...

Πάντως από αυτά που έχω διαβάσει και με τις λίγες γνώσεις που έχω δεν μπορώ να το δω να δουλεύει αν δεν έχουν _πολλούς_ εθελοντές με μεγάλη εμπειρία και πολλές γνώσεις. Το Debian είναι τεράστιο αλλά πιο μεγάλη δυσκολία θα είναι να βγάλουν το systemd από όλα τα χωράφια στα οποία έχει μπει και συνεχίζει να μπαίνει...

 

Ένα διαρκές fork του debian σε κάθε νέα έκδοση (όπως κάνει πχ το Ubuntu) θέλει πολλά χέρια ενώ από την άλλη ένα μεγάλο fork τώρα και ανεξάρτητη πορεία στη συνέχεια είναι νομίζω γιγαντιαία προσπάθεια.

Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Μια κοινότητα κατακερματισμένη, γι' αυτό δεν πάμε μπροστά...

Ετσι. Αλλαζουμε κατι που δουλευει σωστα εδω και χρονια, το τρωμε στη μαπα upstream, κανουμε forks για να χρησιμοποιησουμε ξανα αυτο που δουλευε σωστα στην αρχη.

 

Τα λογια ειναι περιττα...

  • Like 1
Συνδέστε για να σχολιάσετε
Κοινοποίηση σε άλλες σελίδες

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα

  • Δημιουργία νέου...