On Saturday 20 August 2005 16:31, Joel Becker wrote:
On Fri, Aug 19, 2005 at 08:01:17PM -0700, Greg KH wrote:
The recent changes to sysfs should be ported to configfs to do this.
Yeah, I've been meaning to do something, and resusing code is
always a good plan.
Ending up with the same
On Saturday 20 August 2005 20:45, David Howells wrote:
Daniel Phillips [EMAIL PROTECTED] wrote:
Biased. Fs is a mixed case acronym, nuff said.
But I'm still right:-)
Of course you are! We're only impugning your taste, not your logic ;-)
OK, the questions re your global consistency model
On Saturday 20 August 2005 13:01, Greg KH wrote:
On Sat, Aug 20, 2005 at 10:50:51AM +1000, Daniel Phillips wrote:
Permissions set on ConfigFS attributes (aka files) do not stick.
The recent changes to sysfs should be ported to configfs to do this.
No, it should go the other way, my fix
On Saturday 20 August 2005 13:33, Greg KH wrote:
> On Sat, Aug 20, 2005 at 01:23:29PM +1000, Daniel Phillips wrote:
> > On Saturday 20 August 2005 13:01, Greg KH wrote:
> > > On Sat, Aug 20, 2005 at 10:50:51AM +1000, Daniel Phillips wrote:
> > > > So: Integrate wit
On Saturday 20 August 2005 13:01, Greg KH wrote:
> On Sat, Aug 20, 2005 at 10:50:51AM +1000, Daniel Phillips wrote:
> > So: Integrate with sysfs.
>
> No, don't. Do you think that Joel would not have already worked with
> the sysfs people prior to submitting this? No, he did, a
Hi Joel,
Permissions set on ConfigFS attributes (aka files) do not stick. The reason
is that configfs attribute inodes are not pinned and simply disappear after
each file operation. This is good because it saves memory, but it is not
good to throw the permissions away - you then don't have any
On Friday 19 August 2005 20:04, David Howells wrote:
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > I disagree again. I don't think PageFsMisc() is particularly ugly or
> > > unreadable; and it makes it a touch more likely that someone reading
> > > code that uses it will notice that it's a
On Friday 19 August 2005 20:04, David Howells wrote:
Pavel Machek [EMAIL PROTECTED] wrote:
I disagree again. I don't think PageFsMisc() is particularly ugly or
unreadable; and it makes it a touch more likely that someone reading
code that uses it will notice that it's a miscellaneous
Hi Joel,
Permissions set on ConfigFS attributes (aka files) do not stick. The reason
is that configfs attribute inodes are not pinned and simply disappear after
each file operation. This is good because it saves memory, but it is not
good to throw the permissions away - you then don't have any
On Saturday 20 August 2005 13:01, Greg KH wrote:
On Sat, Aug 20, 2005 at 10:50:51AM +1000, Daniel Phillips wrote:
So: Integrate with sysfs.
No, don't. Do you think that Joel would not have already worked with
the sysfs people prior to submitting this? No, he did, and we all
agreed
On Saturday 20 August 2005 13:33, Greg KH wrote:
On Sat, Aug 20, 2005 at 01:23:29PM +1000, Daniel Phillips wrote:
On Saturday 20 August 2005 13:01, Greg KH wrote:
On Sat, Aug 20, 2005 at 10:50:51AM +1000, Daniel Phillips wrote:
So: Integrate with sysfs.
No, don't. Do you think
On Sunday 14 August 2005 05:05, Guillermo López Alejos wrote:
> Hi,
>
> I'm writing documentation about the VFS.
Best of luck. It is a complex topic, but if you manage to produce an accurate
reference, it will be widely read.
> More concretely, I want to
> document the following information
On Sunday 14 August 2005 05:05, Guillermo López Alejos wrote:
Hi,
I'm writing documentation about the VFS.
Best of luck. It is a complex topic, but if you manage to produce an accurate
reference, it will be widely read.
More concretely, I want to
document the following information about
On Monday 15 August 2005 23:15, David Howells wrote:
> I want to know when a page is going to be modified so that I
> can predict the state of the cache as much as possible. I don't want
> userspace processes corrupting the cache in unrecorded ways.
There are two cases:
1) Metadata. If
On Monday 15 August 2005 23:15, David Howells wrote:
I want to know when a page is going to be modified so that I
can predict the state of the cache as much as possible. I don't want
userspace processes corrupting the cache in unrecorded ways.
There are two cases:
1) Metadata. If anybody
On Saturday 13 August 2005 08:20, Rafael J. Wysocki wrote:
> On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
> > I still don't see why you can't lift your flags up into the VMA. The
> > rmap mechanism is there precisely to let you get from the physical page
> >
On Thursday 11 August 2005 20:36, Rafael J. Wysocki wrote:
> > >> > Swsusp is the main "is valid ram" user I have in mind here. It
> > >> > wants to know whether or not it should save and restore the
> > >> > memory of a given `struct page`.
> > >>
> > >> Why can't it follow the rmap chain?
> > >
On Thursday 11 August 2005 20:49, David Howells wrote:
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > To be honest I'm having some trouble following this through logically.
> > I'll read through a few more times and see if that fixes the problem.
> > This seems
On Thursday 11 August 2005 20:49, David Howells wrote:
Daniel Phillips [EMAIL PROTECTED] wrote:
To be honest I'm having some trouble following this through logically.
I'll read through a few more times and see if that fixes the problem.
This seems cluster-related, so I have an interest
On Thursday 11 August 2005 20:36, Rafael J. Wysocki wrote:
Swsusp is the main is valid ram user I have in mind here. It
wants to know whether or not it should save and restore the
memory of a given `struct page`.
Why can't it follow the rmap chain?
It is walking physical
On Saturday 13 August 2005 08:20, Rafael J. Wysocki wrote:
On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
I still don't see why you can't lift your flags up into the VMA. The
rmap mechanism is there precisely to let you get from the physical page
to the users and user data
On Thursday 11 August 2005 19:26, David Howells wrote:
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > + SetPageMiscFS(page);
>
> Can you please retain the *PageFsMisc names I've been using in my stuff?
>
> In my opinion putting the "Fs" bit first gives a cl
On Thursday 11 August 2005 19:46, David Howells wrote:
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > Since this was done only for CacheFS, and Andrew dropped CacheFS from
> > -mm he could drop this patch as well.
>
> I asked him not to. Somewhat at his instigation, I requested that he drop
> the
On Thursday 11 August 2005 19:46, David Howells wrote:
Adrian Bunk [EMAIL PROTECTED] wrote:
Since this was done only for CacheFS, and Andrew dropped CacheFS from
-mm he could drop this patch as well.
I asked him not to. Somewhat at his instigation, I requested that he drop
the filesystem
On Thursday 11 August 2005 19:26, David Howells wrote:
Daniel Phillips [EMAIL PROTECTED] wrote:
+ SetPageMiscFS(page);
Can you please retain the *PageFsMisc names I've been using in my stuff?
In my opinion putting the Fs bit first gives a clearer indication that
this is a bit exclusively
On Thursday 11 August 2005 00:27, David Howells wrote:
> What happens is this:
>
> (1) readpage() is issued against NFS (for example).
>
> (2) NFS consults the local cache, and finds the page isn't available
> there.
>
> (3) NFS reads the page from the server.
>
> (4) NFS sets PG_fs_misc and
Hi Trond,
On Thursday 11 August 2005 08:34, Trond Myklebust wrote:
> to den 11.08.2005 Klokka 08:23 (+1000) skreiv Daniel Phillips:
> > Note: I have not fully audited the NFS-related colliding use of page
> > flags bit 8, to verify that it really does not escape into VFS or
Note: I have not fully audited the NFS-related colliding use of page flags bit
8, to verify that it really does not escape into VFS or MM from NFS, in fact
I have misgivings about end_page_fs_misc which uses this flag but has no
in-tree users to show how it is used and, hmm, isn't even _GPL.
resolves the collision between two different names for the same flag bit.
Signed-off-by: Daniel Phillips <[EMAIL PROTECTED]>
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/afs/dir.c
2.6.13-rc5-mm1/fs/afs/dir.c
--- 2.6.13-rc5-mm1.clean/fs/afs/dir.c 2005-06-17 15:48:29.0 -0400
+++
On Wednesday 10 August 2005 23:13, David Howells wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > ...kill PG_checked please :) Or at least keep it from spreading.
> >
> > It already spread - ext3 is using it and I think reiser4. I thought I
> > had a patch to rename it to PG_misc1 or
On Wednesday 10 August 2005 17:48, Hugh Dickins wrote:
> On Wed, 10 Aug 2005, Daniel Phillips wrote:
> > --- 2.6.13-rc5-mm1.clean/include/linux/page-flags.h 2005-08-09
> > 18:23:31.0 -0400 +++
> > 2.6.13-rc5-mm1/include/linux/page-flags.h 2005-08-09 18:59:57.000
On Wednesday 10 August 2005 17:48, Hugh Dickins wrote:
On Wed, 10 Aug 2005, Daniel Phillips wrote:
--- 2.6.13-rc5-mm1.clean/include/linux/page-flags.h 2005-08-09
18:23:31.0 -0400 +++
2.6.13-rc5-mm1/include/linux/page-flags.h 2005-08-09 18:59:57.0
-0400 @@ -61,7 +61,7
On Wednesday 10 August 2005 23:13, David Howells wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
...kill PG_checked please :) Or at least keep it from spreading.
It already spread - ext3 is using it and I think reiser4. I thought I
had a patch to rename it to PG_misc1 or somesuch, but
resolves the collision between two different names for the same flag bit.
Signed-off-by: Daniel Phillips [EMAIL PROTECTED]
diff -up --recursive 2.6.13-rc5-mm1.clean/fs/afs/dir.c
2.6.13-rc5-mm1/fs/afs/dir.c
--- 2.6.13-rc5-mm1.clean/fs/afs/dir.c 2005-06-17 15:48:29.0 -0400
+++ 2.6.13-rc5
Note: I have not fully audited the NFS-related colliding use of page flags bit
8, to verify that it really does not escape into VFS or MM from NFS, in fact
I have misgivings about end_page_fs_misc which uses this flag but has no
in-tree users to show how it is used and, hmm, isn't even _GPL.
Hi Trond,
On Thursday 11 August 2005 08:34, Trond Myklebust wrote:
to den 11.08.2005 Klokka 08:23 (+1000) skreiv Daniel Phillips:
Note: I have not fully audited the NFS-related colliding use of page
flags bit 8, to verify that it really does not escape into VFS or MM from
NFS, in fact I
On Thursday 11 August 2005 00:27, David Howells wrote:
What happens is this:
(1) readpage() is issued against NFS (for example).
(2) NFS consults the local cache, and finds the page isn't available
there.
(3) NFS reads the page from the server.
(4) NFS sets PG_fs_misc and tells the
On Tuesday 09 August 2005 07:54, Andrew Morton wrote:
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > > Suggestion for your next act:
> >
> > ...kill PG_checked please :) Or at least keep it from spreading.
>
> It already spread - ext3 is using it and I think
Hi Nick,
Did you know that your patches do not actually specify which kernel tree you
diffed against?
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wednesday 10 August 2005 01:36, Hugh Dickins wrote:
> On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
> > - We already have a refcount
> > - We have a field where putting a flag isn't that much of a problem
> > - It can be difficult to get page refcounting right when dealing with
> >
On Wednesday 10 August 2005 06:17, Hugh Dickins wrote:
> There might be a case for packaging repeated arguments into structures
> (though several of these levels are inlined anyway), but that's some
> other exercise entirely, shouldn't get in the way of removing Reserved.
Agreed, an entirely
On Tuesday 09 August 2005 19:49, Nick Piggin wrote:
> Swsusp is the main "is valid ram" user I have in mind here. It
> wants to know whether or not it should save and restore the
> memory of a given `struct page`.
Why can't it follow the rmap chain?
Regards,
Daniel
-
To unsubscribe from this
On Tuesday 09 August 2005 19:49, Nick Piggin wrote:
> Benjamin Herrenschmidt wrote:
> > I have no problem keeping PG_reserved for that, and _ONLY_ for that.
> > (though i'd rather see it renamed then). I'm just afraid by doing so,
> > some drivers will jump in the gap and abuse it again...
>
>
On Tuesday 09 August 2005 10:15, Nick Piggin wrote:
> Daniel Phillips wrote:
> > Why don't you pass the vma in zap_details? For that matter, why are addr
> > and end still passed down the zap chain when zap_details appears to
> > duplicate that information? OK, it is becaus
On Tuesday 09 August 2005 19:49, Nick Piggin wrote:
Benjamin Herrenschmidt wrote:
I have no problem keeping PG_reserved for that, and _ONLY_ for that.
(though i'd rather see it renamed then). I'm just afraid by doing so,
some drivers will jump in the gap and abuse it again...
Sure it
On Tuesday 09 August 2005 19:49, Nick Piggin wrote:
Swsusp is the main is valid ram user I have in mind here. It
wants to know whether or not it should save and restore the
memory of a given `struct page`.
Why can't it follow the rmap chain?
Regards,
Daniel
-
To unsubscribe from this list:
On Wednesday 10 August 2005 06:17, Hugh Dickins wrote:
There might be a case for packaging repeated arguments into structures
(though several of these levels are inlined anyway), but that's some
other exercise entirely, shouldn't get in the way of removing Reserved.
Agreed, an entirely
On Wednesday 10 August 2005 01:36, Hugh Dickins wrote:
On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:
- We already have a refcount
- We have a field where putting a flag isn't that much of a problem
- It can be difficult to get page refcounting right when dealing with
such
Hi Nick,
Did you know that your patches do not actually specify which kernel tree you
diffed against?
Regards,
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tuesday 09 August 2005 07:54, Andrew Morton wrote:
Daniel Phillips [EMAIL PROTECTED] wrote:
Suggestion for your next act:
...kill PG_checked please :) Or at least keep it from spreading.
It already spread - ext3 is using it and I think reiser4. I thought I had
a patch to rename
On Tuesday 09 August 2005 10:15, Nick Piggin wrote:
Daniel Phillips wrote:
Why don't you pass the vma in zap_details? For that matter, why are addr
and end still passed down the zap chain when zap_details appears to
duplicate that information? OK, it is because zap_details is NULL
'Scuse me:
On Tuesday 09 August 2005 07:09, Daniel Phillips wrote:
> Suggestion for your next act:
...kill PG_checked please :) Or at least keep it from spreading.
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
On Sunday 07 August 2005 13:28, Nick Piggin wrote:
> Hi,
>
> I'll be looking to send these off to Andrew after 2.6.14 opens,
> with the aim of having them merged by 2.6.15 hopefully.
>
> It doesn't look like they'll be able to easily free up a page
> flag for 2 reasons. First, PageReserved will
On Sunday 07 August 2005 13:28, Nick Piggin wrote:
Hi,
I'll be looking to send these off to Andrew after 2.6.14 opens,
with the aim of having them merged by 2.6.15 hopefully.
It doesn't look like they'll be able to easily free up a page
flag for 2 reasons. First, PageReserved will probably
'Scuse me:
On Tuesday 09 August 2005 07:09, Daniel Phillips wrote:
Suggestion for your next act:
...kill PG_checked please :) Or at least keep it from spreading.
Regards,
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Saturday 06 August 2005 12:32, Steven Rostedt wrote:
> > > If you need to really get the data out, then the design should be
> > > changed. Have some return value showing the failure, check for
> > > oops_in_progress or whatever, and try again after turning interrupts
> > > back on, and
On Saturday 06 August 2005 12:32, Steven Rostedt wrote:
If you need to really get the data out, then the design should be
changed. Have some return value showing the failure, check for
oops_in_progress or whatever, and try again after turning interrupts
back on, and getting to a point
On Saturday 06 August 2005 11:22, Matt Mackall wrote:
> On Sat, Aug 06, 2005 at 01:51:22AM +0200, Andi Kleen wrote:
> > > But why are we in a hurry to dump the backlog on the floor? Why are we
> > > worrying about the performance of netpoll without the cable plugged in
> > > at all? We shouldn't
On Saturday 06 August 2005 11:22, Matt Mackall wrote:
On Sat, Aug 06, 2005 at 01:51:22AM +0200, Andi Kleen wrote:
But why are we in a hurry to dump the backlog on the floor? Why are we
worrying about the performance of netpoll without the cable plugged in
at all? We shouldn't be
On Thursday 21 July 2005 02:55, Walker, Bruce J (HP-Labs) wrote:
> Like Lars, I too was under the wrong impression about this configfs
> "nodemanager" kernel component. Our discussions in the cluster meeting
> Monday and Tuesday were assuming it was a general service that other
> kernel
On Thursday 21 July 2005 02:55, Walker, Bruce J (HP-Labs) wrote:
Like Lars, I too was under the wrong impression about this configfs
nodemanager kernel component. Our discussions in the cluster meeting
Monday and Tuesday were assuming it was a general service that other
kernel components
On Monday 18 July 2005 16:15, David Teigland wrote:
> I've taken a stab at generalizing ocfs2_nodemanager so the dlm could use
> it (removing ocfs-specific stuff). It still needs some work, but I'd
> like to know if this appeals to the ocfs group and to others who were
> interested in seeing some
On Monday 18 July 2005 16:15, David Teigland wrote:
I've taken a stab at generalizing ocfs2_nodemanager so the dlm could use
it (removing ocfs-specific stuff). It still needs some work, but I'd
like to know if this appeals to the ocfs group and to others who were
interested in seeing some
On Tuesday 19 July 2005 06:12, Jan Engelhardt wrote:
> What is more news to me:
> ( http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ )
> Q: Why was devfs marked OBSOLETE if udev is not finished yet?
> A: To quote Al Viro (Linux VFS kernel maintainer):
> ==> - the devfs
On Tuesday 19 July 2005 06:12, Jan Engelhardt wrote:
What is more news to me:
( http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ )
Q: Why was devfs marked OBSOLETE if udev is not finished yet?
A: To quote Al Viro (Linux VFS kernel maintainer):
== - the devfs
On Friday 08 April 2005 04:38, Andrea Arcangeli wrote:
> On Thu, Apr 07, 2005 at 11:41:29PM -0700, Linus Torvalds wrote:
> The huge number of changesets is the crucial point, there are good
> distributed SCM already but they are apparently not efficient enough at
> handling 60k changesets.
>
>
On Friday 08 April 2005 13:24, Jon Masters wrote:
> On Apr 7, 2005 6:54 PM, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > So I propose that everybody who is interested, pick one of the above
> > projects and join it, to help get it to the point of being able to
> > lo
On Friday 08 April 2005 03:05, Rogan Dawes wrote:
> Take a look at
> http://www.linuxshowcase.org/2001/full_papers/ezolt/ezolt_html/
>
> Abstract
>
> GNU libc's default setting for malloc can cause a significant
> performance penalty for applications that use it extensively, such as
> Compaq's
On Friday 08 April 2005 03:05, Rogan Dawes wrote:
Take a look at
http://www.linuxshowcase.org/2001/full_papers/ezolt/ezolt_html/
Abstract
GNU libc's default setting for malloc can cause a significant
performance penalty for applications that use it extensively, such as
Compaq's high
On Friday 08 April 2005 13:24, Jon Masters wrote:
On Apr 7, 2005 6:54 PM, Daniel Phillips [EMAIL PROTECTED] wrote:
So I propose that everybody who is interested, pick one of the above
projects and join it, to help get it to the point of being able to
losslessly import the version graph
On Friday 08 April 2005 04:38, Andrea Arcangeli wrote:
On Thu, Apr 07, 2005 at 11:41:29PM -0700, Linus Torvalds wrote:
The huge number of changesets is the crucial point, there are good
distributed SCM already but they are apparently not efficient enough at
handling 60k changesets.
We'd need
On Thursday 07 April 2005 13:38, Linus Torvalds wrote:
> On Thu, 7 Apr 2005, Daniel Phillips wrote:
> > In that case, a nice refinement is to put the sequence number at the end
> > of the subject line so patch sequences don't interleave:
>
> No. That makes it unsortable,
On Thursday 07 April 2005 14:13, Dmitry Yusupov wrote:
> On Thu, 2005-04-07 at 13:54 -0400, Daniel Phillips wrote:
> > Three years ago, there was no fully working open source distributed scm
> > code base to use as a starting point, so extending BK would have been the
> >
On Thursday 07 April 2005 14:04, Jörn Engel wrote:
> On Thu, 7 April 2005 10:47:18 -0700, Linus Torvalds wrote:
>> ... There should be some support for cherry-picking in between
> > a temporary throw-away tree and a "cleaned-up-tree". However, it should
> > be something you really do need to think
On Thursday 07 April 2005 13:10, Al Viro wrote:
> The point being, both history and well, publishable result can be expressed
> as series of small steps, but they are not the same thing. So far all I've
> seen in the area (and that includes BK) is heavily biased towards history
> part and
On Thursday 07 April 2005 11:32, Linus Torvalds wrote:
> On Thu, 7 Apr 2005, David Woodhouse wrote:
> > On Wed, 2005-04-06 at 08:42 -0700, Linus Torvalds wrote:
> > > PS. Don't bother telling me about subversion. If you must, start
> > > reading up on "monotone". That seems to be the most viable
On Thursday 07 April 2005 11:10, Linus Torvalds wrote:
> On Thu, 7 Apr 2005, Paul Mackerras wrote:
> > Do you have it automated to the point where processing emailed patches
> > involves little more overhead than doing a bk pull?
>
> It's more overhead, but not a lot. Especially nice numbered
On Wednesday 06 April 2005 23:35, Daniel Phillips wrote:
> When I tried it, it took 13 seconds to 'bzr add' the 2.6.11.3 tree on a
> relatively slow machine.
Oh, and 135 seconds to commit, so 148 seconds overall. Versus 87 seconds to
to bunzip the tree in the first place. So fa
On Wednesday 06 April 2005 23:35, Daniel Phillips wrote:
When I tried it, it took 13 seconds to 'bzr add' the 2.6.11.3 tree on a
relatively slow machine.
Oh, and 135 seconds to commit, so 148 seconds overall. Versus 87 seconds to
to bunzip the tree in the first place. So far, you
On Thursday 07 April 2005 11:10, Linus Torvalds wrote:
On Thu, 7 Apr 2005, Paul Mackerras wrote:
Do you have it automated to the point where processing emailed patches
involves little more overhead than doing a bk pull?
It's more overhead, but not a lot. Especially nice numbered sequences
On Thursday 07 April 2005 11:32, Linus Torvalds wrote:
On Thu, 7 Apr 2005, David Woodhouse wrote:
On Wed, 2005-04-06 at 08:42 -0700, Linus Torvalds wrote:
PS. Don't bother telling me about subversion. If you must, start
reading up on monotone. That seems to be the most viable alternative,
On Thursday 07 April 2005 13:10, Al Viro wrote:
The point being, both history and well, publishable result can be expressed
as series of small steps, but they are not the same thing. So far all I've
seen in the area (and that includes BK) is heavily biased towards history
part and attempts to
On Thursday 07 April 2005 14:04, Jörn Engel wrote:
On Thu, 7 April 2005 10:47:18 -0700, Linus Torvalds wrote:
... There should be some support for cherry-picking in between
a temporary throw-away tree and a cleaned-up-tree. However, it should
be something you really do need to think about,
On Thursday 07 April 2005 14:13, Dmitry Yusupov wrote:
On Thu, 2005-04-07 at 13:54 -0400, Daniel Phillips wrote:
Three years ago, there was no fully working open source distributed scm
code base to use as a starting point, so extending BK would have been the
only easy alternative
On Thursday 07 April 2005 13:38, Linus Torvalds wrote:
On Thu, 7 Apr 2005, Daniel Phillips wrote:
In that case, a nice refinement is to put the sequence number at the end
of the subject line so patch sequences don't interleave:
No. That makes it unsortable, and also much harder to pick put
On Wednesday 06 April 2005 21:40, Martin Pool wrote:
> On Wed, 06 Apr 2005 23:39:11 +0400, Paul P Komkoff Jr wrote:
> > http://bazaar-ng.org/
>
> I'd like bazaar-ng to be considered too. It is not ready for adoption
> yet, but I am working (more than) full time on it and hope to have it
> be
On Wednesday 06 April 2005 11:42, Linus Torvalds wrote:
> it got to the point where I decided that I don't want to be in
> the position of trying to hold two pieces together that would need as much
> glue as it seemed to require.
Hi Linus,
Well I'm really pleased to hear that you won't be
On Wednesday 06 April 2005 11:42, Linus Torvalds wrote:
it got to the point where I decided that I don't want to be in
the position of trying to hold two pieces together that would need as much
glue as it seemed to require.
Hi Linus,
Well I'm really pleased to hear that you won't be drinking
On Wednesday 06 April 2005 21:40, Martin Pool wrote:
On Wed, 06 Apr 2005 23:39:11 +0400, Paul P Komkoff Jr wrote:
http://bazaar-ng.org/
I'd like bazaar-ng to be considered too. It is not ready for adoption
yet, but I am working (more than) full time on it and hope to have it
be usable in a
Greetings,
I am pleased to be able to present today an interesting project that has kept
me busy for the last couple of months.
DDRaid is a cluster block device that, together with a cluster filesystem like
GFS, gives you the ability to operate a "distributed data cluster" where the
cluster
Greetings,
I am pleased to be able to present today an interesting project that has kept
me busy for the last couple of months.
DDRaid is a cluster block device that, together with a cluster filesystem like
GFS, gives you the ability to operate a distributed data cluster where the
cluster
On January 29, 2002 06:25 pm, Rik van Riel wrote:
> On Tue, 29 Jan 2002, Oliver Xymoron wrote:
>
> > Daniel's approach seems to be workable (once he's spelled out all the
> > details) but it misses the big performance win for fork/exec, which is
> > surely the common case. Given that exec will
On January 29, 2002 06:25 pm, Rik van Riel wrote:
On Tue, 29 Jan 2002, Oliver Xymoron wrote:
Daniel's approach seems to be workable (once he's spelled out all the
details) but it misses the big performance win for fork/exec, which is
surely the common case. Given that exec will be
On Thursday 19 July 2001 01:42, Daniel Phillips wrote:
> Yes. The inactive shortage needs to be a function of the length of
> the inactive_dirty queue rather than just the amount that free pages
> is less than some fixed minimum.
Oops, it already is, good :-]
> The t
On Thursday 19 July 2001 01:42, Daniel Phillips wrote:
Yes. The inactive shortage needs to be a function of the length of
the inactive_dirty queue rather than just the amount that free pages
is less than some fixed minimum.
Oops, it already is, good :-]
The target length
> Moreover, when swap is of, the hard disk
> goes crazy as if it where using swap, when in fact it isn't). Is this
> expected behaviour ?
Yes, it's recovering memory by dropping program text pages (memory
mapped from elf files) so those have to be reloaded when the program
executes them again.
On Saturday 07 July 2001 15:50, Jeff Garzik wrote:
> Eugene Crosser wrote:
> > In article
> > <[EMAIL PROTECTED]>,
> >
> > Alexander Viro <[EMAIL PROTECTED]> writes:
> > >> Doesn't the approach "treat a chunk of data built into bzImage
> > >> as populated ramfs" look cleaner? No need to
On Saturday 07 July 2001 15:50, Jeff Garzik wrote:
Eugene Crosser wrote:
In article
[EMAIL PROTECTED],
Alexander Viro [EMAIL PROTECTED] writes:
Doesn't the approach treat a chunk of data built into bzImage
as populated ramfs look cleaner? No need to fiddle with tar
Moreover, when swap is of, the hard disk
goes crazy as if it where using swap, when in fact it isn't). Is this
expected behaviour ?
Yes, it's recovering memory by dropping program text pages (memory
mapped from elf files) so those have to be reloaded when the program
executes them again.
On Friday 06 July 2001 21:09, Rik van Riel wrote:
> On Thu, 5 Jul 2001, Daniel Phillips wrote:
> > Let me comment on this again, having spent a couple of minutes
> > more thinking about it. Would you be happy paying 1% of your
> > battery life to get 80% less sluggish re
601 - 700 of 1437 matches
Mail list logo
