[KERNEL][L / M] 3.4-lollipop-mr1.1 / mit M patch / CM für AOSP-MM - 18.8. / 08.11. / 05.10.16

  • 212 Antworten
  • Letztes Antwortdatum
hmm. ich hatte eigentlich ne zeitlang immer pa als standart rom genutzt und den jwr kernel. Kommt mir komisch vor da ich eigentlich keine probleme hatte, aber das mag nichts heißen. Kannst du evtl. falls möglich ist mit 1710 ein logcat & kmsg machen und hochladen bei den Hängern?. Viele kam seit 02.10 nicht dazu, aber vll. liegts daran (aber glaub ich eigentlich nicht)
Autor: Dave Chinner <dchinner@redhat.com> 2013-07-02 14:38:35
Eintragender: ... 2013-10-07 11:04:11
Eltern: 1e696cc61fd90f00c508e85be025590227de8c25 (kgsl: merge changes added on flo to make the alrgorithm a bit smarter.)
Kind: 848c2069ba0ff73fd3e8243046f61b6036b1ca35 (sound_control: just some cosmetic changes.)
Zweig: cm-10.2-jwr66-mv-oc
Folgt auf: v3.4
Vorgänger von:

sync: don't block the flusher thread waiting on IO

When sync does it's WB_SYNC_ALL writeback, it issues data Io and
then immediately waits for IO completion. This is done in the
context of the flusher thread, and hence completely ties up the
flusher thread for the backing device until all the dirty inodes
have been synced. On filesystems that are dirtying inodes constantly
and quickly, this means the flusher thread can be tied up for
minutes per sync call and hence badly affect system level write IO
performance as the page cache cannot be cleaned quickly.

We already have a wait loop for IO completion for sync(2), so cut
this out of the flusher thread and delegate it to wait_sb_inodes().
Hence we can do rapid IO submission, and then wait for it all to
complete.

Effect of sync on fsmark before the patch:

FSUse% Count Size Files/sec App Overhead
.....
0 640000 4096 35154.6 1026984
0 720000 4096 36740.3 1023844
0 800000 4096 36184.6 916599
0 880000 4096 1282.7 1054367
0 960000 4096 3951.3 918773
0 1040000 4096 40646.2 996448
0 1120000 4096 43610.1 895647
0 1200000 4096 40333.1 921048

And a single sync pass took:

real 0m52.407s
user 0m0.000s
sys 0m0.090s

After the patch, there is no impact on fsmark results, and each
individual sync(2) operation run concurrently with the same fsmark
workload takes roughly 7s:

real 0m6.930s
user 0m0.000s
sys 0m0.039s

IOWs, sync is 7-8x faster on a busy filesystem and does not have an
adverse impact on ongoing async data write operations.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Am Govenor dürfte es nicht liegen, aber am besten ondemand oder interactive benutzen, intellidemand braucht eigentlich kein mensch und eigentlich wars völlig unnötig ihn rein zu nehmen
 
Zuletzt bearbeitet:
Wie kommst du darauf, dass der intelli niemand braucht?

hells
 
war blöd ausgedrückt, ich brauch ihn nicht und ist halt meine meinung, das er eigentlich unnötig ist. Ondemand läuft doch ganz gut und interactive imo auch.
 
Nehme seit Monaten ausschließlich den Intellidemand, bin absolut zufrieden damit und sehe keinen Grund das zu ändern.
 
Mag sein, aber liefs/läufts denn mit ondemand soviel schlechter ?
 
Ja, ondemand und interactive laufen gut, doch nur mit dem intellidemand erreiche ich das, was ich möchte z.B. Der ondemand dreht mir einfach zu oft auf max hoch und der interactive interessiert mich schlicht net, da es einige Sachen gibt, die ihm fehlen, was ondemand und intellidemand aber liefern. Zudem hat der intelli ne dynamische samplingrate, das macht ihn noch interessanter. Ach egal, es nahm mich nur wunder, warum du der Meinung bist, dass er unnötig sei. Für mich bietet er ein paar Vorteile den anderen gegenüber :)

hells
 
Vll. liegts auch daran das mit dieser faux typ irgendwie unsympathisch ist :) (obwohl das natürlich eigentlich auch blöd ist so rein vom lesen her aber ich kanns nicht ändern)
Muss aber auch sagen ich hatte ihn nur kurz ausprobiert.
 
vetzki schrieb:
hmm. ich hatte eigentlich ne zeitlang immer pa als standart rom genutzt und den jwr kernel. Kommt mir komisch vor da ich eigentlich keine probleme hatte, aber das mag nichts heißen. Kannst du evtl. falls möglich ist mit 1710 ein logcat & kmsg machen und hochladen bei den Hängern?. Viele kam seit 02.10 nicht dazu, aber vll. liegts daran (aber glaub ich eigentlich nicht)

Am Govenor dürfte es nicht liegen, aber am besten ondemand oder interactive benutzen, intellidemand braucht eigentlich kein mensch und eigentlich wars völlig unnötig ihn rein zu nehmen


Mach ich nach der Arbeit bzw wenn mal kurz Luft ist.

Ich stell erstmal den Govenor um, vll hilft das schon. :)
 
  • Danke
Reaktionen: vetzki
Sorry ich hab es gestern nicht geschafft, das Log zu erstellen.

Arbeit war mehr als gedacht.

Dazu muss ich aber auch Fragen welche App ich dafür brauche. Hahaha
 
Über ADB wäre nicht schlecht (für kmsg mit adb shell cat /proc/kmsg) für logcat Catlog oder alogcat (oder einfach über adb mit adb logcat), wenns geht wenn der Hänger kommt (am besten an pc hängen logcat/kmsg "starten" dann die app und den hänger provozieren.
(kmsg geht auch easy über last_kmsg, d.h. wenn der hänger da war rebooten und Datei auf die sd sichern).

danke falls klappt/du Lust hast würde mich interessieren warum (hoffentlich sieht man in den logs was)
 
So hier sind die Logs. Hoffentlich kann man was erkennen. :confused2:
 

Anhänge

  • 2013-10-22_18.45.zip
    52,1 KB · Aufrufe: 119
danke. Ich schau aber erst morgen, einzig auf die schnelle last_kmsg is von bricked und war das die zip vom 17.10?
 
Ja war sie.

Mach in Ruhe. Handy läuft ja an sich flüssig. Das mit WhatsApp Überlebe ich. :)

Gesendet von meinem Nexus 4 mit der Android-Hilfe.de App
 
Okay, ich weiß jetzt grad nicht welche Datei ich für die aktuelle CM Nightly brauche, kann mir jemand helfen, die Dateinamen verwirren mich etwas :D
 
Erster Spoiler aufklappen, ganz unten:

source (cm/kernel/google/msm)
für cm:
Download - cm - CM : klick / 17.10. / geht nur mit aktuellen nightlies
Download - cm - CM - Kein OC : klick / 17.10. / geht nur mit aktuellen nightlies
 
CM ist doch gar nicht mehr JSS, die sind doch jetzt CAF :) ?
 
Das ist noch der alte Name
 
  • Danke
Reaktionen: Galaxyfire
Danke, ich dachte schon ich müsste wieder elend lange nach diesem "color-fix" suchen :D Werd mich melden, wie er ist

EDIT: Läuft bisher gut :)
 
Zuletzt bearbeitet:
Kazama schrieb:
So hier sind die Logs. Hoffentlich kann man was erkennen. :confused2:

Servus,

erstmal danke für die logs, du nutzt slim oder? hab mir jetzt stock jwr installiert und geschaut, bei mir sind (bisher) jedoch keine Hänger bei Whatsapp beim schreiben aufgetreten (aber hab gesehen das immer noch touch_boost failed das log vollspammt, dachte das hätte ich rausbekommen muss da nochmal schaun). Ich schau auch mal das ich slim installiere und muss mal dann sehen.

nutzt du ne andere Tastatur oder die die von haus aus drin ist?

(ich weiß nicht obs evtl. daran liegt
E/SpannableStringBuilder(32440): SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length, hängt auf alle fälle mit der tastatur zusammen aber sollte glaube ich nicht für die freezes verantwortlich sein)
 
  • Danke
Reaktionen: Kazama

Ähnliche Themen

droidjam
Antworten
7
Aufrufe
2.538
droidjam
droidjam
vetzki
Antworten
1
Aufrufe
2.288
vetzki
vetzki
C
  • ChrisFX19
Antworten
2
Aufrufe
1.955
rihntrha
R
Zurück
Oben Unten