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.(
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
Allan McRae, le Mon 11 Jan 2010 10:55:56 +1000, a écrit :
> As Lenny was released about the same time that patch
> hit cvs/git, I am guessing that a patch was never needed for this
> particular issue.
Yes it was: unstable saw an upgrade to 2.9 first, and then to 2.10
Samuel
Samuel Thibault wrote:
Allan McRae, le Mon 11 Jan 2010 09:15:51 +1000, a écrit :
Samuel Thibault wrote:
Allan McRae, le Sun 10 Jan 2010 19:59:01 +1000, a écrit :
Is there another patch for glibc-2.7 to fix this or, even better, a
patch-set for a newer glibc version?
You can peek debian's patc
Allan McRae, le Mon 11 Jan 2010 09:15:51 +1000, a écrit :
> Samuel Thibault wrote:
> >Allan McRae, le Sun 10 Jan 2010 19:59:01 +1000, a écrit :
> >> Is there another patch for glibc-2.7 to fix this or, even better, a
> >>patch-set for a newer glibc version?
> >
> >You can peek debian's patchset.
>
Samuel Thibault wrote:
Allan McRae, le Sun 10 Jan 2010 19:59:01 +1000, a écrit :
Is there another patch for glibc-2.7 to fix this or, even better, a
patch-set for a newer glibc version?
You can peek debian's patchset.
Thanks. I guess this is an answer for the latter part of that question,
Allan McRae, le Sun 10 Jan 2010 19:59:01 +1000, a écrit :
> Is there another patch for glibc-2.7 to fix this or, even better, a
> patch-set for a newer glibc version?
You can peek debian's patchset.
Samuel
Hi,
I am trying to cross-compile a GNU system and have run into an "issue"
compiling Hurd. Currently, I am cross-compiling with binutils-2.19.1,
gcc-4.1.2 and glibc-2.7 using the patches from here:
http://www.schwinge.homeip.net/~thomas/tmp/glibc-patches/ (all 00xx-
patches, cvs-MSG_NOSIGNA
> What is the relationship between the Hurd and glibc? By this I mean,
> which version of glibc is appropriate to use when working with the Hurd.
> Is the glibc source from Debian the proper one to use?
I compiled glibc from savannah and used it with the Hurd recently
without problems
On Mon, Oct 22, 2001 at 04:28:06PM -0700, Ian Duggan wrote:
>
> What is the relationship between the Hurd and glibc?
AFAIK, glibc was written by Roland for the Hurd from the ground up,
and later it was extended to cover Linux as well.
> By this I mean,
> which version of glibc is
What is the relationship between the Hurd and glibc? By this I mean,
which version of glibc is appropriate to use when working with the Hurd.
Is the glibc source from Debian the proper one to use?
It seems that awhile back, glibc used to be in the Hurd CVS, but now it
is not. How often are
29 matches
Mail list logo
