diff options
| author | Thomas Schwinge <thomas@codesourcery.com> | 2013-10-27 19:44:32 +0100 |
|---|---|---|
| committer | Thomas Schwinge <thomas@codesourcery.com> | 2013-10-27 19:44:32 +0100 |
| commit | 9675f765a06325bcbd5ac58a9eee8856cb2c5b7c (patch) | |
| tree | 359703ed392ac61d3d4ff783c814e01a39fc2ff2 /hurd/translator/ext2fs.mdwn | |
| parent | 8fac6986eadf6db5d155030cc67a904f22cadf29 (diff) | |
| parent | 47e4d194dc36adfcfd2577fa4630c9fcded005d3 (diff) | |
Merge remote-tracking branch 'fp/master'
Diffstat (limited to 'hurd/translator/ext2fs.mdwn')
| -rw-r--r-- | hurd/translator/ext2fs.mdwn | 38 |
1 files changed, 5 insertions, 33 deletions
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index e2f6b044..cfd09502 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -163,6 +163,11 @@ small backend stores, like floppy devices. <youpi> ok +#### IRC, freenode, #hurd, 2013-10-08 + + <braunr> ogi: your ext2fs patches were finally merged upstream :) + + ## Sync Interval [[!tag open_issue_hurd]] @@ -209,39 +214,6 @@ That would be a nice improvement, but only after writeback throttling is impleme <teythoon> tschwinge: well, thanks anyway ;) -## Increased Memory Consumption - -### IRC, freenode, #hurd, 2013-09-18 - - <braunr> ext2fs is using a ginormous amount of memory on darnassus since i - last updated the hurd package :/ - <braunr> i wonder if my ext2fs large store patches rework have introduced a - regression - <braunr> the order of magnitude here is around 1.5G virtual space :/ - <braunr> it used to take up to 3 times less before that - <braunr> looks like my patches didn't make it into the latest hurd package - <braunr> teythoon: looks like there definitely is a new leak in ext2fs - <teythoon> :/ - <braunr> memory only - <braunr> the number of ports looks stable relative to file system usage - <teythoon> braunr: I tested my patches on my development machine, it's up - for 14 days (yay libvirt :) and never encountered problems like this - <braunr> i've been building glibc to reach that state - <teythoon> hm, that's a heavy load indeed - <teythoon> could be the file name tracking stuff, I tried to make sure that - everything is freed, but I might have missed something - <braunr> teythoon: simply running htop run shows a slight, regular increase - in physical memory usage in ext2fs - <pinotree> old procfs stikes again? :) - <teythoon> braunr: I see that as well... curious... - <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried - to make sure that everything is freed, but I might have missed something - <braunr> how knows, maybe completely unrelated - <teythoon> the tracking patch isn't that big, I've gone over it twice today - and it still seems reasonable to me - <braunr> hm - - # Documentation * <http://e2fsprogs.sourceforge.net/ext2.html> |