On Tue, 27 Feb 2007, Andrew Morton wrote:
> > On Mon, 26 Feb 2007 17:35:17 -0800 Stephen Hemminger <[EMAIL PROTECTED]>
> > wrote:
> > The kernel already has several implmentations and usages of 64 by 64
> > bit divide.
> >
> > Although it is significantly slower, there are places that need it
On Tue, 27 Feb 2007, Andrew Morton wrote:
On Mon, 26 Feb 2007 17:35:17 -0800 Stephen Hemminger [EMAIL PROTECTED]
wrote:
The kernel already has several implmentations and usages of 64 by 64
bit divide.
Although it is significantly slower, there are places that need it so
provide
On Fri, 16 Feb 2007, Andrew Morton wrote:
> No, that's still crufty. There's no reason why marker.h needs special
> treatment whereas, say, jiffies.h does not (is there?)
Unforunately, even jiffies.h gets special treatment. sched.h still
includes jiffies.h, as this is where it was originally
On Wed, 14 Feb 2007, Johann Schuster wrote:
> currently i'm trying to measure the cpu times for
> numerical algorithms written in C using two calls of
> getrusage() and then calculating the time difference.
>
> According to the man page of getrusage i looked at the
> user time of my process.
On Wed, 14 Feb 2007, Johann Schuster wrote:
currently i'm trying to measure the cpu times for
numerical algorithms written in C using two calls of
getrusage() and then calculating the time difference.
According to the man page of getrusage i looked at the
user time of my process.
On Fri, 16 Feb 2007, Andrew Morton wrote:
No, that's still crufty. There's no reason why marker.h needs special
treatment whereas, say, jiffies.h does not (is there?)
Unforunately, even jiffies.h gets special treatment. sched.h still
includes jiffies.h, as this is where it was originally
On Sun, 4 Feb 2007, Mathieu Desnoyers wrote:
> kernel/time/clocksource.c needs struct task_struct on m68k.
>
> Because it uses spin_unlock_irq(), which, on m68k, uses hardirq_count(), which
> uses preempt_count(), which needs to dereference struct task_struct, we
> have to include sched.h.
On Sun, 4 Feb 2007, Mathieu Desnoyers wrote:
kernel/time/clocksource.c needs struct task_struct on m68k.
Because it uses spin_unlock_irq(), which, on m68k, uses hardirq_count(), which
uses preempt_count(), which needs to dereference struct task_struct, we
have to include sched.h. Because it
On Sun, 4 Feb 2007, Ahmed S. Darwish wrote:
> On Sat, Feb 03, 2007 at 11:56:16PM +0100, Richard Knutsson wrote:
> > So:
> >
> > if (is_true()) {
> > /* do something */
> > }
> >
> > is alright then? If so, I agree, but please make it real clear in the
> > document ;)
>
> Good catch :). A
On Sun, 4 Feb 2007, Ahmed S. Darwish wrote:
On Sat, Feb 03, 2007 at 11:56:16PM +0100, Richard Knutsson wrote:
So:
if (is_true()) {
/* do something */
}
is alright then? If so, I agree, but please make it real clear in the
document ;)
Good catch :). A small grep of
On Thu, 1 Feb 2007, [EMAIL PROTECTED] wrote:
> On Thu, 01 Feb 2007 13:39:15 +0100, Tim Schmielau said:
> > #define is_power_of_4(x) (is_power_of_2_or_zero(x) \
> > && (x & ((typeof(x))0x)))
>
> Those 5's are going to need m
On Thu, 1 Feb 2007, David Howells wrote:
> Robert P. J. Day <[EMAIL PROTECTED]> wrote:
>
> > +#define is_power_of_4(x) is_power_of_2(x) && (ffs(x) & 1))
>
> If this is such a commonly implemented op, it should probably be implemented
> globally too.
>
> I also wonder if there's some better
On Thu, 1 Feb 2007, David Howells wrote:
Robert P. J. Day [EMAIL PROTECTED] wrote:
+#define is_power_of_4(x) is_power_of_2(x) (ffs(x) 1))
If this is such a commonly implemented op, it should probably be implemented
globally too.
I also wonder if there's some better way of
On Thu, 1 Feb 2007, [EMAIL PROTECTED] wrote:
On Thu, 01 Feb 2007 13:39:15 +0100, Tim Schmielau said:
#define is_power_of_4(x) (is_power_of_2_or_zero(x) \
(x ((typeof(x))0x)))
Those 5's are going to need more magic if x is a 64-bit typeof?
Yeah, I can't
On Tue, 30 Jan 2007, Tom Burns wrote:
> That would be great if you could find that patch - I can worry about
> porting it to the current kernel. We're having an issue where our
> device, while routing large amounts of network traffic, reports 0% CPU
> utilisation when it cannot be the case, and
On Tue, 30 Jan 2007, Tom Burns wrote:
> The bug described back in 2004 in the following message still seems to exist:
>
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-05/4313.html
>
> Essentially, it appears that if a process sleeps before it uses up a
> complete jiffy then no charge is
On Tue, 30 Jan 2007, Tom Burns wrote:
The bug described back in 2004 in the following message still seems to exist:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-05/4313.html
Essentially, it appears that if a process sleeps before it uses up a
complete jiffy then no charge is made
On Tue, 30 Jan 2007, Tom Burns wrote:
That would be great if you could find that patch - I can worry about
porting it to the current kernel. We're having an issue where our
device, while routing large amounts of network traffic, reports 0% CPU
utilisation when it cannot be the case, and I
On Fri, 26 Jan 2007, Oleg Verych wrote:
> In Debian's version it has no `bc', while native `bc' is producing
> crap like that:
> ,-*- bash -*-
> |[EMAIL PROTECTED]:~$ printf "%u" $(( -1 )) ; echo
> |18446744073709551615
> |[EMAIL PROTECTED]:~$ echo -1 | bc
> |-1
> |[EMAIL PROTECTED]:~$ printf
On Fri, 26 Jan 2007, Oleg Verych wrote:
In Debian's version it has no `bc', while native `bc' is producing
crap like that:
,-*- bash -*-
|[EMAIL PROTECTED]:~$ printf %u $(( -1 )) ; echo
|18446744073709551615
|[EMAIL PROTECTED]:~$ echo -1 | bc
|-1
|[EMAIL PROTECTED]:~$ printf %u $(( 0xFF
On Sun, 21 Jan 2007, Sunil Naidu wrote:
> On 1/21/07, Tim Schmielau <[EMAIL PROTECTED]> wrote:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data
> > doesn't actually get written to disk in that time. For some enlightening
> &g
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> On Sat, Jan 20, 2007 at 09:39:25PM +0100, Tim Schmielau wrote:
> > On Sat, 20 Jan 2007, Willy Tarreau wrote:
> > > On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> > >
> > > > also explains why yo
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data
> > doesn't actually get written to disk in that time. For some enlightening
&
On Sat, 20 Jan 2007, Willy Tarreau wrote:
> Anyway, in your situation with a very small buffer, this should not
> change by more than half a second or so.
Well, his buffer is not small. He has half a GB of RAM, so when
writing 1 GB the buffer would roughly double the dd speed, exactly as he
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau şunları yazmıştı:
> >
> > Note that these dd "benchmarks" are completely bogus, because the data=20
> > doesn't actually get written to disk in that time. For som
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
> 20 Oca 2007 Cts 19:45 tarihinde şunları yazmıştınız:
> [...]
> > > vaio cartman # hdparm -tT /dev/hda
> > >
> > > /dev/hda:
> > > Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
> > > Timing buffered disk reads: 74 MB in 3.01
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
20 Oca 2007 Cts 19:45 tarihinde şunları yazmıştınız:
[...]
vaio cartman # hdparm -tT /dev/hda
/dev/hda:
Timing cached reads: 1576 MB in 2.00 seconds = 788.18 MB/sec
Timing buffered disk reads: 74 MB in 3.01 seconds = 24.55 MB/sec
On Sat, 20 Jan 2007, Ismail Dönmez wrote:
20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau şunları yazmıştı:
Note that these dd benchmarks are completely bogus, because the data=20
doesn't actually get written to disk in that time. For some enlightening=20
data, try
time dd if=3D
On Sat, 20 Jan 2007, Willy Tarreau wrote:
Anyway, in your situation with a very small buffer, this should not
change by more than half a second or so.
Well, his buffer is not small. He has half a GB of RAM, so when
writing 1 GB the buffer would roughly double the dd speed, exactly as he
has
On Sat, 20 Jan 2007, Willy Tarreau wrote:
On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
Note that these dd benchmarks are completely bogus, because the data
doesn't actually get written to disk in that time. For some enlightening
data, try
time dd if=/dev/zero
On Sat, 20 Jan 2007, Willy Tarreau wrote:
On Sat, Jan 20, 2007 at 09:39:25PM +0100, Tim Schmielau wrote:
On Sat, 20 Jan 2007, Willy Tarreau wrote:
On Sat, Jan 20, 2007 at 09:10:22PM +0100, Tim Schmielau wrote:
also explains why you see better results is writeout starts earlier
On Sun, 21 Jan 2007, Sunil Naidu wrote:
On 1/21/07, Tim Schmielau [EMAIL PROTECTED] wrote:
Note that these dd benchmarks are completely bogus, because the data
doesn't actually get written to disk in that time. For some enlightening
data, try
time dd if=/dev/zero of=/tmp/1GB bs=1M
On Thu, 18 Jan 2007, Robert P. J. Day wrote:
> actually, it *appears* that the standard works this way. the macro
> "__deprecated" is defined in compiler-gcc.h with:
>
> #define __deprecated __attribute__((deprecated))
>
> while the more generic compiler.h handles whether or not it was
>
On Thu, 18 Jan 2007, Robert P. J. Day wrote:
> Centralize the attribute macro definition of "__packed" so no
> subsystem has to do that explicitly.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> compile tested to make sure the HFS subsystem still builds. now
> there's
On Thu, 18 Jan 2007, Robert P. J. Day wrote:
Centralize the attribute macro definition of __packed so no
subsystem has to do that explicitly.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
compile tested to make sure the HFS subsystem still builds. now
there's just 50
On Thu, 18 Jan 2007, Robert P. J. Day wrote:
actually, it *appears* that the standard works this way. the macro
__deprecated is defined in compiler-gcc.h with:
#define __deprecated __attribute__((deprecated))
while the more generic compiler.h handles whether or not it was
defined:
On Wed, 10 Jan 2007, Geert Uytterhoeven wrote:
> which needs the definition of struct task_struct.
>
> The patch below fixes it by including in
> kernel/time/clocksource.c. But perhaps this is the right time to move
> struct task_struct to its own include instead?
I used to post such a patch
On Wed, 10 Jan 2007, Geert Uytterhoeven wrote:
which needs the definition of struct task_struct.
The patch below fixes it by including linux/sched.h in
kernel/time/clocksource.c. But perhaps this is the right time to move
struct task_struct to its own include instead?
I used to post such a
On Sat, 6 Jan 2007, Stefan Richter wrote:
> Did anybody else notice this? The result of "hdparm -t" under 2.6.20-rc
> seems to be less than half of what you get on 2.6.19. However, disk I/O
> did *not* get slower according to bonnie++.
yes. See
http://lkml.org/lkml/2007/1/2/75
for the
On Sat, 6 Jan 2007, Stefan Richter wrote:
Did anybody else notice this? The result of hdparm -t under 2.6.20-rc
seems to be less than half of what you get on 2.6.19. However, disk I/O
did *not* get slower according to bonnie++.
yes. See
http://lkml.org/lkml/2007/1/2/75
for the solution.
On Fri, 5 Jan 2007, Mariusz Kozlowski wrote:
> Doesn't build on my iMac G3 based garage jukebox ;-)
>
> arch/powerpc/kernel/of_platform.c:479: error: unknown field
> 'multithread_probe' specified in initializer
> arch/powerpc/kernel/of_platform.c:479: warning: initialization makes pointer
On Fri, 5 Jan 2007, Mariusz Kozlowski wrote:
Doesn't build on my iMac G3 based garage jukebox ;-)
arch/powerpc/kernel/of_platform.c:479: error: unknown field
'multithread_probe' specified in initializer
arch/powerpc/kernel/of_platform.c:479: warning: initialization makes pointer
Well, on a P4 (which is supposed to be soo bad) I get:
> gcc -O2 t.c -o t
> foreach x ( 1 2 3 4 5 )
>> time ./t > /dev/null
>> end
0.196u 0.004s 0:00.19 100.0%0+0k 0+0io 0pf+0w
0.168u 0.004s 0:00.16 100.0%0+0k 0+0io 0pf+0w
0.168u 0.000s 0:00.16 100.0%0+0k 0+0io 0pf+0w
0.160u 0.000s
Well, on a P4 (which is supposed to be soo bad) I get:
gcc -O2 t.c -o t
foreach x ( 1 2 3 4 5 )
time ./t /dev/null
end
0.196u 0.004s 0:00.19 100.0%0+0k 0+0io 0pf+0w
0.168u 0.004s 0:00.16 100.0%0+0k 0+0io 0pf+0w
0.168u 0.000s 0:00.16 100.0%0+0k 0+0io 0pf+0w
0.160u 0.000s 0:00.15
On Fri, 29 Dec 2006, Tim Schmielau wrote:
> Andrew, please use the attached patch instead of the previous one, it also
> has a slightly better patch description.
This time I actually attached something. Sorry.
(In case anybody wonders: yes, I did get some sleep while the builds were
r
On Thu, 28 Dec 2006, Randy Dunlap wrote:
> Yep, right, if I already had all of that cross-build stuff setup,
> it wouldn't be a big deal. But getting it all setup is a big deal
> (to me).
Well, I didn't want to say that you specifically should do that. ;-)
OTOH, if you are interested, setting
On Thu, 28 Dec 2006, Tim Schmielau wrote:
> On Thu, 28 Dec 2006, Russell King wrote:
>
> > To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
> > netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
>
> OK, I'll try to do that.
On Thu, 28 Dec 2006, Tim Schmielau wrote:
On Thu, 28 Dec 2006, Russell King wrote:
To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
OK, I'll try to do that.
Do I need to build all the configs
On Thu, 28 Dec 2006, Randy Dunlap wrote:
Yep, right, if I already had all of that cross-build stuff setup,
it wouldn't be a big deal. But getting it all setup is a big deal
(to me).
Well, I didn't want to say that you specifically should do that. ;-)
OTOH, if you are interested, setting it
On Fri, 29 Dec 2006, Tim Schmielau wrote:
Andrew, please use the attached patch instead of the previous one, it also
has a slightly better patch description.
This time I actually attached something. Sorry.
(In case anybody wonders: yes, I did get some sleep while the builds were
running
On Thu, 28 Dec 2006, Randy Dunlap wrote:
> On Thu, 28 Dec 2006 21:48:30 + Russell King wrote:
> > On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
> > > On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
> > > > The whole "all*config" idea on ARM is utterly useless - you can
On Thu, 28 Dec 2006, Russell King wrote:
> I'm talking about cross-builds... I don't know the spec of the machine,
> only that it's x86 based (I don't run it.)
>
> The last report at the beginning of this month said: 11 1/2 hours per
> git snapshot, which is apparantly for building a total of
On Thu, 28 Dec 2006, Russell King wrote:
> Given that it takes about 8 to 12 hours to do a build cycle, that's
My build cycle takes about 2 hours for 4 configs, on a decent AMD64
system (running completely in tmpfs). Am I doing something wrong or are
you talking about native builds?
Tim
-
To
On Thu, 28 Dec 2006, Russell King wrote:
> To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
> netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
OK, I'll try to do that.
Do I need to build all the configs in arch/arm/configs?
> The whole "all*config"
On Thu, 28 Dec 2006, Al Viro wrote:
> Uh-huh. How much of build coverage have you got with it?
Well, as said in the patch description, I compiled alpha, arm, i386, ia64,
mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and
allyesconfig as well as a few randconfigs on
On Thu, 28 Dec 2006, Randy Dunlap wrote:
> I'm half done with a patch to remove includes of smp_lock.h.
> For the files that I have patched, I checked each source file
> for all interfaces in smp_lock.h to verify that none of them
> are used, so the #include is just waste.
Yes, that's what I
On Thu, 28 Dec 2006, Andrew Morton wrote:
> On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
> Tim Schmielau <[EMAIL PROTECTED]> wrote:
>
> > After Al Viro (finally) succeeded in removing the sched.h #include in
> > module.h recently, it makes sense again to remove oth
After fiddling with this patch for so long, I forgot to mention an
important thing:
This time the patch only includes things that need no fixups at all (most
of these already went in last time).
So all hunks are independent, and you can just drop anything that does not
apply or causes any
-off-by: Tim Schmielau <[EMAIL PROTECTED]>
Patch attached as .bz2 due to it's size (160k uncompressed).
remove-556-unneeded-includes-of-schedh.patch.bz2
Description: BZip2 compressed data
On Thu, 28 Dec 2006, Randy Dunlap wrote:
On Thu, 28 Dec 2006 21:48:30 + Russell King wrote:
On Thu, Dec 28, 2006 at 01:32:46PM -0800, Randy Dunlap wrote:
On Thu, 28 Dec 2006 21:34:38 + Russell King wrote:
The whole all*config idea on ARM is utterly useless - you can _not_
get
-off-by: Tim Schmielau [EMAIL PROTECTED]
Patch attached as .bz2 due to it's size (160k uncompressed).
remove-556-unneeded-includes-of-schedh.patch.bz2
Description: BZip2 compressed data
After fiddling with this patch for so long, I forgot to mention an
important thing:
This time the patch only includes things that need no fixups at all (most
of these already went in last time).
So all hunks are independent, and you can just drop anything that does not
apply or causes any
On Thu, 28 Dec 2006, Andrew Morton wrote:
On Thu, 28 Dec 2006 21:27:40 +0100 (CET)
Tim Schmielau [EMAIL PROTECTED] wrote:
After Al Viro (finally) succeeded in removing the sched.h #include in
module.h recently, it makes sense again to remove other superfluous
sched.h includes.
Why
On Thu, 28 Dec 2006, Randy Dunlap wrote:
I'm half done with a patch to remove includes of smp_lock.h.
For the files that I have patched, I checked each source file
for all interfaces in smp_lock.h to verify that none of them
are used, so the #include is just waste.
Yes, that's what I also
On Thu, 28 Dec 2006, Al Viro wrote:
Uh-huh. How much of build coverage have you got with it?
Well, as said in the patch description, I compiled alpha, arm, i386, ia64,
mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and
allyesconfig as well as a few randconfigs on
On Thu, 28 Dec 2006, Russell King wrote:
To cover these, you need to build at least rpc_defconfig, lubbock_defconfig,
netwinder_defconfig, badge4_defconfig, cerf_defconfig, ...etc...
OK, I'll try to do that.
Do I need to build all the configs in arch/arm/configs?
The whole all*config idea on
On Thu, 28 Dec 2006, Russell King wrote:
Given that it takes about 8 to 12 hours to do a build cycle, that's
My build cycle takes about 2 hours for 4 configs, on a decent AMD64
system (running completely in tmpfs). Am I doing something wrong or are
you talking about native builds?
Tim
-
To
On Thu, 28 Dec 2006, Russell King wrote:
I'm talking about cross-builds... I don't know the spec of the machine,
only that it's x86 based (I don't run it.)
The last report at the beginning of this month said: 11 1/2 hours per
git snapshot, which is apparantly for building a total of about
On Sat, 16 Dec 2006, J.H. wrote:
> - Gitweb is causing us no end of headache,
Is there any mirror for http://git.kernel.org/git/ other than
git2.kernel.org? If there is, it would probably help to make it better
known.
thanks,
Tim
-
To unsubscribe from this list: send the line "unsubscribe
On Sat, 16 Dec 2006, J.H. wrote:
- Gitweb is causing us no end of headache,
Is there any mirror for http://git.kernel.org/git/ other than
git2.kernel.org? If there is, it would probably help to make it better
known.
thanks,
Tim
-
To unsubscribe from this list: send the line unsubscribe
On Sat, 16 Dec 2006, Robert P. J. Day wrote:
> On Fri, 15 Dec 2006, Tim Schmielau wrote:
> >
> > It might be interesting to grep for anything that divides two
> > sizeofs and eyeball the result for possible mistakes. This would
> > provide some real benefit beyond the
On Sat, 16 Dec 2006, Robert P. J. Day wrote:
On Fri, 15 Dec 2006, Tim Schmielau wrote:
It might be interesting to grep for anything that divides two
sizeofs and eyeball the result for possible mistakes. This would
provide some real benefit beyond the cosmetical changes.
i did
On Fri, 15 Dec 2006, Robert P. J. Day wrote:
> On Fri, 15 Dec 2006, Jan Engelhardt wrote:
> > Even sizeof a / sizeof *a
> >
> > may happen.
>
> yes, sadly, there are a number of those as well. back to the drawing
> board.
It might be interesting to grep for anything that divides two sizeofs
On Fri, 15 Dec 2006, Robert P. J. Day wrote:
On Fri, 15 Dec 2006, Jan Engelhardt wrote:
Even sizeof a / sizeof *a
may happen.
yes, sadly, there are a number of those as well. back to the drawing
board.
It might be interesting to grep for anything that divides two sizeofs and
eyeball
> but it still leaves an open issue -- once one submits a patch, is there
> *any* official feedback that one can look for to see if it's been
> accepted/rejected/dropped on the floor/whatever?
You can regularely pull Linus' tree (or the tree of the maintainer you
sent your patch) and see
but it still leaves an open issue -- once one submits a patch, is there
*any* official feedback that one can look for to see if it's been
accepted/rejected/dropped on the floor/whatever?
You can regularely pull Linus' tree (or the tree of the maintainer you
sent your patch) and see whether
On Mon, 4 Dec 2006, Aucoin wrote:
> > From: Horst H. von Brand [mailto:[EMAIL PROTECTED]
> > That means that there isn't a need for that memory at all (and so they
>
> In the current isolated non-production, not actually bearing a load test
> case yes. But if I can't get it to not swap on an
On Mon, 4 Dec 2006, Aucoin wrote:
From: Horst H. von Brand [mailto:[EMAIL PROTECTED]
That means that there isn't a need for that memory at all (and so they
In the current isolated non-production, not actually bearing a load test
case yes. But if I can't get it to not swap on an idle
On Sun, 3 Dec 2006, Aucoin wrote:
> during tar extraction ... inactive pages reaches levels as high as ~375000
So why do you want the system to swap _less_? You need to find some free
memory for the additional processes to run in, and you have lots of
inactive pages, so I think you want to
On Sun, 3 Dec 2006, Aucoin wrote:
during tar extraction ... inactive pages reaches levels as high as ~375000
So why do you want the system to swap _less_? You need to find some free
memory for the additional processes to run in, and you have lots of
inactive pages, so I think you want to swap
On Fri, 1 Dec 2006, Adrian Bunk wrote:
> On Fri, Dec 01, 2006 at 01:41:18PM +0100, Tim Schmielau wrote:
[...]
> > would leave a comment that is correct, but less useful (I'd expect any
> > kernel hacker to know that u64 is non-atomic on many platforms).
>
>
> If ker
> Chase Venters (1):
> Fix jiffies.h comment
This one actually obscures the comment rather than fixing it.
>From jiffies.h:
> 76 /*
> 77 * The 64-bit value is not volatile - you MUST NOT read it
> 78 * without sampling the sequence number in xtime_lock.
> 79 * get_jiffies_64() will do
Chase Venters (1):
Fix jiffies.h comment
This one actually obscures the comment rather than fixing it.
From jiffies.h:
76 /*
77 * The 64-bit value is not volatile - you MUST NOT read it
78 * without sampling the sequence number in xtime_lock.
79 * get_jiffies_64() will do this for
On Fri, 1 Dec 2006, Adrian Bunk wrote:
On Fri, Dec 01, 2006 at 01:41:18PM +0100, Tim Schmielau wrote:
[...]
would leave a comment that is correct, but less useful (I'd expect any
kernel hacker to know that u64 is non-atomic on many platforms).
If kernel hackers are expected to already
SKGE surely isn't a meta driver. Not that this is relevant at all...
Signed-off-by: Tim Schmielau <[EMAIL PROTECTED]>
--- linux-2.6.13/drivers/net/Kconfig2005-08-29 01:41:01.0 +0200
+++ linux-2.6.13-skge/drivers/net/Kconfig 2005-09-08 10:57:38.0
+0200
@@ -
SKGE surely isn't a meta driver. Not that this is relevant at all...
Signed-off-by: Tim Schmielau [EMAIL PROTECTED]
--- linux-2.6.13/drivers/net/Kconfig2005-08-29 01:41:01.0 +0200
+++ linux-2.6.13-skge/drivers/net/Kconfig 2005-09-08 10:57:38.0
+0200
@@ -1928,7 +1928,7
On Wed, 2 Mar 2005, Guillaume Thouvenin wrote:
> Is it possible to merge BSD and CSA? I mean with CSA, there is a part
> that does per-process accounting. For exemple in the
> linux-2.6.9.acct_mm.patch the two functions update_mem_hiwater() and
> csa_update_integrals() update fields in the
On Wed, 2 Mar 2005, Guillaume Thouvenin wrote:
Is it possible to merge BSD and CSA? I mean with CSA, there is a part
that does per-process accounting. For exemple in the
linux-2.6.9.acct_mm.patch the two functions update_mem_hiwater() and
csa_update_integrals() update fields in the current
> > +#ifdef CONFIG_FORK_CONNECTOR
[...]
> > +static inline void fork_connector(pid_t parent, pid_t child)
> > +{
[...]
> > +}
> > +#else
> > +static inline void fork_connector(pid_t parent, pid_t child)
> > +{
> > + return;
> > +}
> > +#endif
[...]
> > @@ -1238,6 +1281,8 @@ long
On Fri, 25 Feb 2005, Mark Fortescue wrote:
> The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be
> correct. I had some errors during patching so I generated a diff against a
> freshly downloaded linux-2.6.10 kernel. See the steps below:
>
> 1) bzcat linux-2.6.8.1.tar.bz2 | tar
On Fri, 25 Feb 2005, Mark Fortescue wrote:
The kernel patch files patch-2.6.9 and patch-2.6.10 do not apear to be
correct. I had some errors during patching so I generated a diff against a
freshly downloaded linux-2.6.10 kernel. See the steps below:
1) bzcat linux-2.6.8.1.tar.bz2 | tar -xf
+#ifdef CONFIG_FORK_CONNECTOR
[...]
+static inline void fork_connector(pid_t parent, pid_t child)
+{
[...]
+}
+#else
+static inline void fork_connector(pid_t parent, pid_t child)
+{
+ return;
+}
+#endif
[...]
@@ -1238,6 +1281,8 @@ long do_fork(unsigned long clone_flags,
On Tue, 22 Feb 2005, Andrew Morton wrote:
> We really want to avoid doing such stuff in-kernel if at all possible, of
> course.
>
> Is it not possible to implement the fork/exec/exit notifications to
> userspace so that a daemon can track the process relationships and perform
> aggregation based
On Tue, 22 Feb 2005, Andrew Morton wrote:
We really want to avoid doing such stuff in-kernel if at all possible, of
course.
Is it not possible to implement the fork/exec/exit notifications to
userspace so that a daemon can track the process relationships and perform
aggregation based upon
> Hi Vise People,
>
>
> ASUS P2B-DS board seems NOT work very well with default kernel in FED
> Core 3. smp-kernel hangs booting at various stages. I am goig to try
> 2.6.10 today. non-smp-kernel boots fine. This is my first time I try to
> test with smp-kernels so I don't know what I could
Hi Vise People,
GH1N2J3JKL - this helps, me to find answers - please keep line
ASUS P2B-DS board seems NOT work very well with default kernel in FED
Core 3. smp-kernel hangs booting at various stages. I am goig to try
2.6.10 today. non-smp-kernel boots fine. This is my first time I try to
On Thu, 3 Feb 2005, Andrew Morton wrote:
> Well your patch certainly cleans things up in there and would be a good
> thing to have as long as we can be sure that it doesn't break the
> accounting in some subtle way.
I think it also fits well with the other accounting data which is only
On Thu, 3 Feb 2005, Pankaj Agarwal wrote:
> In my system there's a strange behaviour its not allowing me to create
> any file in /usr/bin even as root. Its chmod is set to 755. Its even not
> allowing me to change the chmod value of /usr/bin. The strangest part which
> i felt is ...its
On Thu, 3 Feb 2005, Pankaj Agarwal wrote:
In my system there's a strange behaviour its not allowing me to create
any file in /usr/bin even as root. Its chmod is set to 755. Its even not
allowing me to change the chmod value of /usr/bin. The strangest part which
i felt is ...its shows
On Thu, 3 Feb 2005, Andrew Morton wrote:
Well your patch certainly cleans things up in there and would be a good
thing to have as long as we can be sure that it doesn't break the
accounting in some subtle way.
I think it also fits well with the other accounting data which is only
1 - 100 of 112 matches
Mail list logo
