Damned: The latest pdf file was shown in xpdf, still not in the attachment when
sent! Re-attching the latest version.
On Wed, 2016-05-18 at 15:05 +0200, Svante Signell wrote:
> On Thu, 2016-05-05 at 19:05 +0200, Richard Braun wrote:
> >
> > On Wed, Apr 20, 2016 at 11:40:39AM +0200, Richard Braun
On Thu, 2016-05-05 at 19:05 +0200, Richard Braun wrote:
> On Wed, Apr 20, 2016 at 11:40:39AM +0200, Richard Braun wrote:
> >
> > I wrote an incomplete vm_map_enter in X15 [1] that should be helpful.
> > In addition to a free hint pointer, it uses the red-black tree, making
> > all allocations at w
On Wed, Apr 20, 2016 at 11:40:39AM +0200, Richard Braun wrote:
> I wrote an incomplete vm_map_enter in X15 [1] that should be helpful.
> In addition to a free hint pointer, it uses the red-black tree, making
> all allocations at worst O(n). If anyone feels like doing that little
> task, enjoy yours
BTW, I have also commited rules to build the hurd-prof package. This
can however only built with a fixed gcc package ; the patch is pending
upload, I have put built binaries on
http://people.debian.org/~sthibault/tmp/
and then you uncomment the hurd-prof entry in debian/control, and build
with dpk
Samuel Thibault, on Wed 20 Apr 2016 10:52:06 +0200, wrote:
> Samuel Thibault, on Wed 20 Apr 2016 01:07:09 +0200, wrote:
> > Samuel Thibault, on Tue 19 Apr 2016 12:18:01 +0200, wrote:
> > > Svante Signell, on Tue 19 Apr 2016 12:08:07 +0200, wrote:
> > > > > Looking at ps -feMj, it seems that it's ex
Richard Braun, on Wed 20 Apr 2016 11:53:27 +0200, wrote:
> On Wed, Apr 20, 2016 at 11:44:36AM +0200, Samuel Thibault wrote:
> > Richard Braun, on Wed 20 Apr 2016 11:40:39 +0200, wrote:
> > > I wrote an incomplete vm_map_enter in X15 [1] that should be helpful.
> > > In addition to a free hint point
On Wed, Apr 20, 2016 at 11:44:36AM +0200, Samuel Thibault wrote:
> Richard Braun, on Wed 20 Apr 2016 11:40:39 +0200, wrote:
> > I wrote an incomplete vm_map_enter in X15 [1] that should be helpful.
> > In addition to a free hint pointer, it uses the red-black tree, making
> > all allocations at wor
Richard Braun, on Wed 20 Apr 2016 11:40:39 +0200, wrote:
> I wrote an incomplete vm_map_enter in X15 [1] that should be helpful.
> In addition to a free hint pointer, it uses the red-black tree, making
> all allocations at worst O(n).
Well, the current algorithm also has O(n) worst case :)
But I g
On Wed, Apr 20, 2016 at 10:52:06AM +0200, Samuel Thibault wrote:
> Here is the profiling for the new policy.
Impressive. And as often, this shows how actual measurement is so much
better than guessing :).
> Most of the time, these are contiguous, so it's kind of stupid to look
> again at each and
Samuel Thibault, on Wed 20 Apr 2016 01:07:09 +0200, wrote:
> Samuel Thibault, on Tue 19 Apr 2016 12:18:01 +0200, wrote:
> > Svante Signell, on Tue 19 Apr 2016 12:08:07 +0200, wrote:
> > > > Looking at ps -feMj, it seems that it's ext2fs which consumes much more
> > > > CPU time, thus increasing ove
Samuel Thibault, on Tue 19 Apr 2016 12:18:01 +0200, wrote:
> (note that fields such as "self
> seconds" seem to have a bug: they should be 100x bigger, most probably
> yet another issue with the announcement of the kernel clock rate):
BTW, I fixed that, it was a dumb bug in glibc.
Samuel
Samuel Thibault, on Tue 19 Apr 2016 12:18:01 +0200, wrote:
> Svante Signell, on Tue 19 Apr 2016 12:08:07 +0200, wrote:
> > > Looking at ps -feMj, it seems that it's ext2fs which consumes much more
> > > CPU time, thus increasing overall wallclock time. It'd probably be
> > > interesting to profile
On Tue, Apr 19, 2016 at 12:18:01PM +0200, Samuel Thibault wrote:
> The last remark makes me think that the performance issue being raised
> is in the kernel, not in userland.
I expect it's the VP table backing the page cache. I'm currently
continuing Justus' work in the last GSoC to back VM object
On Sun, 2016-04-17 at 22:24 +0200, Samuel Thibault wrote:
> Hello,
>
> Thanks for the investigation. I have added the attached patch to the
> gnumach running on the buildds. That'll revert to the old page cache
> policy, which seems to be reverting to the previous performance.
Build times are no
On Mon, Apr 18, 2016 at 02:04:26AM +0200, Samuel Thibault wrote:
> I'm not saying we should revert the work :)
>
> I'm saying I'm reverting it to work around the issue on buildds for now.
> Perhaps we can also apply the revert on the debian package.
No I understand, I just want to make this clear
Richard Braun, on Mon 18 Apr 2016 01:29:13 +0200, wrote:
> On Sun, Apr 17, 2016 at 10:24:32PM +0200, Samuel Thibault wrote:
> > Looking at ps -feMj, it seems that it's ext2fs which consumes much more
> > CPU time, thus increasing overall wallclock time. It'd probably be
> > interesting to profile e
On Sun, Apr 17, 2016 at 10:24:32PM +0200, Samuel Thibault wrote:
> Thanks for the investigation. I have added the attached patch to the
> gnumach running on the buildds. That'll revert to the old page cache
> policy, which seems to be reverting to the previous performance.
>
> Looking at ps -feMj
Hello,
Thanks for the investigation. I have added the attached patch to the
gnumach running on the buildds. That'll revert to the old page cache
policy, which seems to be reverting to the previous performance.
Looking at ps -feMj, it seems that it's ext2fs which consumes much more
CPU time, thus
On Thu, 2016-04-14 at 13:16 +0200, Svante Signell wrote:
> Hello,
>
> In order to track down why the latest releases of gnumach, hurd and
> glibc have
> become so much slower building packages, I did a few (non-scientific)
> build
> tests, as shown in the attached pdf file.(I have also put it on
Hello,
In order to track down why the latest releases of gnumach, hurd and glibc have
become so much slower building packages, I did a few (non-scientific) build
tests, as shown in the attached pdf file.(I have also put it on my web page on
Darnassus.)
>From the build times in that file, one can
20 matches
Mail list logo
