> the default on ia64 (32MB) was way too large
Agreed. It took about 9 minutes to search the first pair of cpus
(cpu 0 to cpu 1) from a size of 67107840 down to a size of 62906,
based on some prints I added since my last message.
> it seems the screen blanking timer hit
Ah - yes. That makes s
Herbert Xu wrote:
The question is what happens when you compress 1 1GiB input buffer into
a 1GiB output buffer.
If user provides 1 GB output buffer then either we successfully compress
all the 1 GB input or we compress just a part of it.
In the former case user may provide a second output buffer
Artem B. Bityuckiy wrote:
In the former case user may provide a second output buffer and
s/former/latter/
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
Sorry :-)
Artem B. Bityuckiy wrote:
In case of crypto_comp_pcompress() if the input isn't compressible,
s/crypto_comp_pcompress()/crypto_comp_compress()/
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Sun, Apr 03, 2005 at 12:22:12PM +0400, Artem B. Bityuckiy wrote:
>
> The latter case is possible if the input isn't compressible and it is up
> to user to detect that handle this situation properly (i.e., just not to
> compress this). So, IMO, there are no problems here at least for the
> cr
Jörn Engel wrote:
> Absolutely. You can argue that 4KiB is too small and 8|16|32|64|...
> would be much better, yielding in better compression ratio. But
> having to read and uncompress the whole file when appending a few
> bytes is utter madness.
>
Dear Joern,
I meant that JFFS2 always reads by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday, 03 April 2005, at 01:31:30 +0200,
Jesper Juhl wrote:
> Have you tried 2.6.12-rc1-bk5 or 2.6.12-rc1-mm4 to see if the bug has
> already been fixed ?
>
Just tried 2.6.12-rc1-bk5, and it works OK. Sorry for the noise.
Greetings,
- --
Jose
On Sat, Apr 02, 2005 at 10:21:50PM -0800, Paul E. McKenney wrote:
> The synchronize_kernel() primitive is used for quite a few different
> purposes: waiting for RCU readers, waiting for NMIs, waiting for interrupts,
> and so on. This makes RCU code harder to read, since synchronize_kernel()
> migh
Herbert Xu wrote:
Surely that defeats the purpose of pcompress? I thought the whole point
was to compress as much of the input as possible into the output?
Absolutely correct.
So 1G into 1G doesn't make sense here.
I thought you are afraid about the case of a totally random input which
may *grow*
Earlier, Paul wrote:
> Note the first 3 chars of the panic message "4.5". This looks like it
> might be the [00]-[01] entry of Ingo's table, flushed out when the
> newlines of the panic came through.
For the record, the above speculation is probably wrong.
More likely, the first six characters "
On Tue, Mar 29, 2005 at 09:15:43PM +0200, Pavel Machek wrote:
> This fixes u32 vs. pm_message_t confusion in arm. I was not able to
> even compile it, but it should not cause any problems. Please apply,
Applied, thanks.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.
Herbert Xu wrote:
On Sun, Apr 03, 2005 at 12:22:12PM +0400, Artem B. Bityuckiy wrote:
The latter case is possible if the input isn't compressible and it is up
to user to detect that handle this situation properly (i.e., just not to
compress this). So, IMO, there are no problems here at least for
On Sun, Apr 03, 2005 at 12:59:23PM +0400, Artem B. Bityuckiy wrote:
>
> Err, it looks like we've lost the conversation flow. :-) I commented
> your phrase: "The question is what happens when you compress 1 1GiB
> input buffer into a 1GiB output buffer."
>
> Then could you please in a nutshell w
On Mar 24, 2005 12:41 AM, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-03-23 at 09:40 -0500, Stephen Smalley wrote:
> > This patch adds a name_connect permission check to SELinux to provide
> > control over outbound TCP connections to particular ports distinct
> > from the general cont
Herbert Xu wrote:
You can't compress 1M-12bytes into 1M using zlib when the block size
is 64K.
Here is a cite from RFC-1951 (page 4):
A compressed data set consists of a series of blocks, corresponding
to successive blocks of input data. The block sizes are arbitrary,
except that non-com
On Sat, 2005-04-02 at 11:30 -0800, Andrew Morton wrote:
> Did it work OK under any other kernel versions? If so, which?
At least it works in 2.6.7, I jump from .7 to .9 then .10 and
finally .11, I notice this problem in 2.6.10 firstly.
If you need addictional info about the drive just ask.
I f
On Sun, Apr 03, 2005 at 01:45:58PM +0400, Artem B. Bityuckiy wrote:
>
> Here is a cite from RFC-1951 (page 4):
>
>A compressed data set consists of a series of blocks, corresponding
>to successive blocks of input data. The block sizes are arbitrary,
>except that non-compressible bloc
On Sun, 2005-04-03 at 20:00 +1000, Herbert Xu wrote:
> > 1. 64K is only applied to non-compressible data, in which case zlib just
> > copies it as it is, adding a 1-byte header and a 1-byte EOB marker.
>
> I think the overhead could be higher. But even if it is 2 bytes
> per block, then for 1M o
On Sun, Apr 03, 2005 at 11:06:01AM +0100, David Woodhouse wrote:
>
> We're not interested in the _total_ overhead, in this context. We're
> interested in the number of bytes we have to have available in the
> output buffer in order to let zlib finish its stream.
>
> In the case of a 1MiB input ge
Herbert Xu wrote:
On Sun, Apr 03, 2005 at 01:45:58PM +0400, Artem B. Bityuckiy wrote:
I think the overhead could be higher.
IIUC, not. But I'll check this in practice.
But even if it is 2 bytes
Ok, suppose.
per block, then for 1M of incompressible input the total overhead is
2 * 1048576 / 65536 =
try turning off your internal modem in bios until someone works out whats going
on here
SuD (Alex) wrote:
Hi, i got a new ahtec laptop and i get null pointer oops everytime i
load i810_audio on 2.4 and 2.6 (including 2.6.11.6) kernels.
*** These are init messages & oops:
i810_audio: Unknown symb
Herbert Xu wrote:
You might be right. But I'm not sure yet.
If we use the current code and supply zlib_deflate with 1048576-12 bytes
of (incompressible) input and 1048576 bytes of output buffer, wouldn't
zlib keep writing incompressible blocks and return when it can't do that
anymore because the o
On Tue, Mar 29, 2005 at 09:15:43PM +0200, Pavel Machek wrote:
> This fixes u32 vs. pm_message_t confusion in arm. I was not able to
> even compile it, but it should not cause any problems. Please apply,
On testing this patch, it doesn't build. You need to include
linux/pm.h into linux/sysdev.h fo
Hi!
> > This fixes u32 vs. pm_message_t confusion in arm. I was not able to
> > even compile it, but it should not cause any problems. Please apply,
>
> On testing this patch, it doesn't build. You need to include
> linux/pm.h into linux/sysdev.h for starters, and fix sysdev.h
> to also use pm_m
In their comapany blurb to investors, they also claim "in-house approach
to R&D and design", "The design of most product components", including
"control software". No mention is made of Linux and an equally hard rub,
it's only supposed to talk to Windows and Mac.
Regards
Sid.
--
Sid Boyce ... Ha
On Sun, 3 Apr 2005, Arun Srinivas wrote:
>
> I looked at my "include/asm-i386/param.h" and the HZ value is 1000.So, I
> suppose the timer interrupt frequency is 1000 times per sec. or once every 1
> millisec.
>
> So, is scheduler_tick() ( for resceduling) called only once every 1 ms?? I am
> mea
On Sun, 2005-04-03 at 20:17 +1000, Herbert Xu wrote:
> You might be right. But I'm not sure yet.
>
> If we use the current code and supply zlib_deflate with 1048576-12
> bytes of (incompressible) input and 1048576 bytes of output buffer,
> wouldn't zlib keep writing incompressible blocks and retu
Ok - that flies, or at least walks. It took 53 seconds to
compute this cost matrix.
Here's what it prints, on a small 8 CPU ia64 SN2 Altix, with
the migration_debug prints formatted separately from the primary
table, for ease of reading:
Total of 8 processors activated (15548.60 BogoMIPS).
-
Yum Rayan <[EMAIL PROTECTED]> writes:
> Attempt to reduce stack usage in acct.c (linux-2.6.12-rc1-mm3). Stack
> usage was noted using checkstack.pl. Specifically:
>
> Before patch
>
> check_free_space - 128
>
> After patch
> ---
> check_free_space - 36
>
> Signed-off-by: Yum R
On Sun, Apr 03, 2005 at 12:19:17PM +0100, David Woodhouse wrote:
>
> But now we're not using Z_SYNC_FLUSH it doesn't matter if we feed the
> input in smaller chunks. We can calculate a conservative estimate of the
> amount we'll fit, and keep feeding it input till the amount of space
> left in the
Herbert,
I also wonder, does it at all correct to use negative windowBits in
crypto API? I mean, if windowBits is negative, zlib doesn't produce the
proper zstream header, which is incorrect according to RFC-1950. It also
doesn't calculate adler32.
For example, if we work over an IP network (RF
On Sun, Apr 03, 2005 at 02:23:42PM +0400, Artem B. Bityuckiy wrote:
>
> It must not. Look at the algoritm closer.
This relies on implementation details within zlib_deflate, which may
or may not be the case.
It should be easy to test though. Just write a user-space program
which does exactly this
On Sun, Apr 03, 2005 at 03:41:07PM +0400, Artem B. Bityuckiy wrote:
>
> I also wonder, does it at all correct to use negative windowBits in
> crypto API? I mean, if windowBits is negative, zlib doesn't produce the
It's absolutely correct for IPComp. For other uses it may or may not
be correct.
Herbert Xu wrote:
Can you please point me to the paragraph in RFC 1950 that says this?
Ok, if to do s/correct/compliant/, here it is:
Section 2.3, page 7
---
A compliant compressor must produce streams with correct CMF, FLG and
AD
Hi,
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal (not interface) use. In my tests, key setup on Athlon 64 slows
down by 40% when using u32 instead of uint_fast32_t.
So I wonder if there is any st
Herbert Xu wrote:
On Sun, Apr 03, 2005 at 03:41:07PM +0400, Artem B. Bityuckiy wrote:
I also wonder, does it at all correct to use negative windowBits in
crypto API? I mean, if windowBits is negative, zlib doesn't produce the
It's absolutely correct for IPComp. For other uses it may or may not
On Sun, Apr 03, 2005 at 03:53:40PM +0400, Artem B. Bityuckiy wrote:
> Herbert Xu wrote:
> >Can you please point me to the paragraph in RFC 1950 that says this?
>
> Ok, if to do s/correct/compliant/, here it is:
>
> Section 2.3, page 7
Sorry, I thought you were referring to an RFC that defined IP
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
>
> I've been working on a new DES implementation for Linux, and ran into
> the problem of how to get access to C99 types like uint_fast32_t for
> internal (not interface) use. In my tests, key setup on Athlon 64 slows
>
On Sun, Apr 03, 2005 at 04:01:19PM +0400, Artem B. Bityuckiy wrote:
>
> >For instance for JFFS2 it's absolutely incorrect since it breaks
> >compatibility. Incidentally, JFFS should create a new compression
> >type that doesn't include the zlib header so that we don't need the
> >head-skipping sp
On Sat, Apr 02, 2005 at 04:28:40PM -0800, Andrew Morton wrote:
>
> *** These are init messages & oops:
> i810_audio: Unknown symbol ac97_set_dac_rate
> i810_audio: Unknown symbol ac97_release_codec
> i810_audio: Unknown symbol ac97_set_adc_rate
> i810_audio: Unknown symbol ac97_alloc_codec
> i810_
Herbert Xu wrote:
Each crypto/deflate user gets their own private zlib instance.
Where is the problem?
Hmm, OK. No problems, that was just RFC. :-)
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Sun, Apr 03, 2005 at 10:14:27PM +1000, herbert wrote:
>
> I personally don't see a reason why we should allow it to
> continue when the codec doesn't exist. What do you guys think?
Actually, anybody trying to use this driver without a codec
would've hit the same crash. Since nobody has compl
Stephen Rothwell wrote:
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal (not interface) use. In my tests, key setup on
On Sat, 2 Apr 2005 13:19:44 -0500 (EST), Christopher Allen Wing wrote:
>On Sat, 2 Apr 2005, Mikael Pettersson wrote:
>
>> >APIC error on CPU0: 00(40)
>> >APIC error on CPU0: 40(40)
>>
>> Those are "received illegal vector" errors, and they
>> typically indicate hardware flakiness or BIOS is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch, compiled against version 2.6.12-rc1, implements RCU mechanism in
intermodule functions.
Signed-off-by: Luca Falavigna <[EMAIL PROTECTED]>
- --- ./kernel/intermodule.c.orig 2005-04-01 19:25:26.0 +
+++ ./kernel/intermodu
Hello,
I tried the recent 2.6.12-rc1-bk5 snapshot from kernel.org.
When I want to boot my x86_64 system only a green line appears on screen.
The config is the same as in 2.6.12-rc1-bk4 which works flawlessly on my
system.
I only saw the message that CPU0 and CPU1 where initialized. And then
there
> I tried the recent 2.6.12-rc1-bk5 snapshot from kernel.org.
> When I want to boot my x86_64 system only a green line appears on screen.
> The config is the same as in 2.6.12-rc1-bk4 which works flawlessly on my
> system.
>
> I only saw the message that CPU0 and CPU1 where initialized. And then
>
Nick Piggin wrote:
This actually improves performance noticably (ie. a % or so) on schedule /
wakeup happy benchmarks (tbench, on a dual Xeon with HT using mwait idle).
Here are some numbers on a 2 socket Xeon with HT and mwait idle.
Average of 3 runs, tbench, single client and single server proces
Dag Arne Osvik <[EMAIL PROTECTED]> writes:
> Yes, but wouldn't it be much better to avoid code like the following,
> which may also be wrong (in terms of speed)?
>
> #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
> #define fast_u32 u64
> #else
> #define fast_u32 u32
> #endif
How about using j
Peter Baumann wrote:
On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote:
Peter Baumann <[EMAIL PROTECTED]> wrote:
I'm hitting an annoying bug in kernel 2.6.11.5
Every time I _reboot_ (warmstart) my pc my two network cards won't get
recognized any longer.
Following error message appears o
Thanks Alexander this sort this out.
No system boots w/o problems :-)
Alexander Nyberg wrote:
>>I tried the recent 2.6.12-rc1-bk5 snapshot from kernel.org.
>>When I want to boot my x86_64 system only a green line appears on screen.
>>The config is the same as in 2.6.12-rc1-bk4 which works flawles
This patch had removed obsolete VR41xx RTC function from vr41xx.h .
I forgot to put this change in "update VR41xx RTC support".
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/include/asm-mips/vr41xx/vr41xx.h
rc1-mm4/include/asm-mips/vr41xx/vr41xx.h
---
On 31/3/2005, at 08:30, John Pearson wrote:
E.g.: suppose there are 2 snack bars within 100 yards of a school; one
is out of sight, across an intersection and down a side street, and one
is clearly visible across an empty lot. For years the lot has been
unfenced and, human nature being what it is,
Three more observations.
1) The slowest measure_one() calls are, not surprisingly, those for the
largest sizes. At least on my test system of the moment, the plot
of cost versus size has one major maximum (a one hump camel, not two).
Seems like if we computed from smallest size
Hi Paul,
I'm not quite clear on the difference between the two synchronize functions ,
the comment for synchronize_sched() seems to have a bit missing? (see below)
cheers
On Sun, 3 Apr 2005 16:21, Paul E. McKenney wrote:
> +/**
> + * synchronize_sched - block until all CPUs have exited any non-
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Ok - that flies, or at least walks. It took 53 seconds to compute
> this cost matrix.
53 seconds is too much - i'm working on reducing it.
> Here's what it prints, on a small 8 CPU ia64 SN2 Altix, with
> the migration_debug prints formatted separate
While testing the page placement policy patches on 2.6.12-rc1, I noticed
that aim9 is showing significant slowdowns on page allocation-related
tests. An excerpt of the results is at the end of this mail but it shows
that page_test is allocating 18000 less pages.
I did not check who has been recen
i386/kernel/entry.S:resume_kernel: is used on return path
from do_IRQ() which leaves interrupts disabled. And we have
preempt_stop == cli in ret_from_exception: case, before
ret_from_intr. So this 'cli' is unneeded.
It is ok to enter schedule() with interrupts disabled, so
this 'sti' in preempt_sc
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Three more observations.
>
> 1) The slowest measure_one() calls are, not surprisingly, those for the
> largest sizes. At least on my test system of the moment, the plot
> of cost versus size has one major maximum (a one hump camel, not two).
Em Fri, Apr 01, 2005 at 10:44:31PM -0800, Andrew Morton escreveu:
> Jon Smirl <[EMAIL PROTECTED]> wrote:
> >
> > This will let me boot again. It is not obvious to me where the problem
> > is, it may have something to do with netlink or maybe memory
> > corruption?
> >
> > bk export -tpatch -r1.
Em Sat, Apr 02, 2005 at 01:46:03PM -0600, James Bottomley escreveu:
> Well, this is a brown paper bag for someone. The new protocol
/me using such bag now :(
Thanks a lot for the fix.
David, Please apply.
> registration locking uses a rwlock to limit access to the protocol list.
> Unfortunatel
* Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> 3) I was noticing that my test system was only showing a couple of
> distinct values for cpu_distance, even though it has 4 distinct
> distances for values of node_distance. So I coded up a variant of
> cpu_distance that converts the
Herbert Xu wrote:
This relies on implementation details within zlib_deflate, which may
or may not be the case.
It should be easy to test though. Just write a user-space program
which does exactly this and feed it something from /dev/urandom.
Well, Herbert, you're right. In case of non-compressible
On Sun, 2005-04-03 at 13:17 +0200, Jesper Juhl wrote:
>
> A reschedule can happen once every ms, but also upon returning to
> userspace and when returning from an interrupt handler, and also when
> something in the kernel explicitly calls schedule() or sleeps (which in
> turn results in a call
Hi,
I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
(Everyting run smoothly using 2.6.11-mm1)
It seems to be related with mounting a reiserfs3 filesystem.
Please also note that this kernel was compiled using gcc-4.0-0pre9
(from Debian)
I'm using mount 2.12p
Please CC: me.
Here t
Em Fri, Apr 01, 2005 at 10:30:42PM -0500, Jon Smirl escreveu:
> This is what I see on boot.
>
> --
> Jon Smirl
> [EMAIL PROTECTED]
>
> Linux version 2.6.12-rc1 ([EMAIL PROTECTED]) (gcc version
> 3.4.2 200410
> 17 (Red Hat 3.4.2-6.fc3)) #21 SMP Fri Apr 1 22:09:28 EST 2005
> found SMP MP-table at
Esben Stien <[EMAIL PROTECTED]> writes:
> Jeremy Nickurak <[EMAIL PROTECTED]> writes:
>
>> I'm playing with this under 2.6.11.4
>
> I got 2.6.12-rc1
>
>> The vertical cruise control buttons work properly, with the
>> exception of the extra button press.
>
> Yup, nice, I see the same
Same here.
Errr. That was my oversight. I will compile-test the patches
against all sub-archs in future. Thanks for catching this
and sending the patch.
Thanks,
Venki
>-Original Message-
>From: James Bottomley [mailto:[EMAIL PROTECTED]
>Sent: Saturday, April 02, 2005 10:10 AM
>To: Andrew Morto
On Apr 3, 2005 11:51 AM, Arnaldo Carvalho de Melo
<[EMAIL PROTECTED]> wrote:
> Em Fri, Apr 01, 2005 at 10:30:42PM -0500, Jon Smirl escreveu:
> > This is what I see on boot.
> >
> > --
> > Jon Smirl
> > [EMAIL PROTECTED]
> >
> > Linux version 2.6.12-rc1 ([EMAIL PROTECTED]) (gcc version
> > 3.4.2 200
On Sat, Apr 02, 2005 at 11:28:12AM +, Luca Falavigna wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This patch, compiled against version 2.6.12-rc1, implements RCU mechanism in
> intermodule functions.
There's no point as these functions are going to go away soon.
-
To unsubscr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all:
I am trying to make my Avermedia TV/Phone 98 remote control work with
linux kernel 2.6.x input layer support (driver ir-kbd-gpio). Module bttv
detects the remote ("bttv0: add subdevice "remote0"), and "ir-kbd-gpio"
makes the remote control sho
On Apr 02, 2005, at 06:28, Luca Falavigna wrote:
-BEGIN PGP SIGNED MESSAGE-
- --- ./kernel/intermodule.c.orig 2005-04-01 19:25:26.0 +
+++ ./kernel/intermodule.c 2005-04-02 02:46:22.0 +
@@ -3,7 +3,7 @@
/* Written by Keith Owens Oct 2000 */
#include
#in
Hi,
As told, I tested it w/o nvidia module loaded, here's what I found:
1. It now doesn't hang on scanning for devices.
2. It now hangs on acquiring preview, logs will follow.
2a.Not it hanged on scanning for devices again, don't know why.
3. It's true for both module loaded and w/o it.
4. xsane ba
On Sun, 2005-04-03 at 09:10 +0200, Manfred Spraul wrote:
> Yes - sem or spin locks are quicker as long as no cache line transfers
> are necessary. If the semaphore is accessed by multiple cpus, then
> kmalloc would be faster: slab tries hard to avoid taking global locks.
> I'm not speaking abou
Actually, please do NOT apply this. It conflicts with other
patches, which have been in the past few MM releases, have
also been circulated on linux-usb-devel, and actually address
some of the bugs which crept in as things have changed around
the USB stack.
- Dave
-
To unsubscribe from this list:
On Sun, Apr 03, 2005 at 02:30:11PM +0200, Dag Arne Osvik wrote:
> Yes, but wouldn't it be much better to avoid code like the following,
> which may also be wrong (in terms of speed)?
>
> #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
> #define fast_u32 u64
> #else
> #define fast_u32 u32
> #end
On Sun, Apr 03, 2005 at 02:26:50PM +0530, Dipankar Sarma wrote:
> On Sat, Apr 02, 2005 at 10:21:50PM -0800, Paul E. McKenney wrote:
> > The synchronize_kernel() primitive is used for quite a few different
> > purposes: waiting for RCU readers, waiting for NMIs, waiting for interrupts,
> > and so on
On Mon, Apr 04, 2005 at 12:11:56AM +1000, Michael Ellerman wrote:
> Hi Paul,
>
> I'm not quite clear on the difference between the two synchronize functions ,
> the comment for synchronize_sched() seems to have a bit missing? (see below)
>
> cheers
>
> On Sun, 3 Apr 2005 16:21, Paul E. McKenney
On Sun, 2005-04-03 at 15:37 +0100, Mel Gorman wrote:
> While testing the page placement policy patches on 2.6.12-rc1, I noticed
> that aim9 is showing significant slowdowns on page allocation-related
> tests. An excerpt of the results is at the end of this mail but it shows
> that page_test is allo
On Sat, Mar 12, 2005 at 11:32:29PM -0500, Ryan Anderson wrote:
>
> Sam, you'll probably want this on top of the patch I sent. (I haven't
> built in a clean tree in a while, found a minor problem when I was
> transitioning to quilt today.)
Combined this to one patch and applied it.
Let's see what
On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote:
Stephen Rothwell wrote:
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal
Steven Rostedt wrote:
On Sun, 2005-04-03 at 09:10 +0200, Manfred Spraul wrote:
Yes - sem or spin locks are quicker as long as no cache line transfers
are necessary. If the semaphore is accessed by multiple cpus, then
kmalloc would be faster: slab tries hard to avoid taking global locks.
I'm n
On Sat, Mar 19, 2005 at 07:28:00PM -0500, Ryan Anderson wrote:
> On Mon, Mar 14, 2005 at 11:59:26AM -0800, Ajay Patel wrote:
> > I had a similar problem building binrpm-pkg.
> > Try following patch. It worked for me.
>
> My problem wasn't actually resolved by this - the make in builddeb still
> ca
Patches 1-3 are fine.
Protocol switching via sysfs works too but if I switch from LBPS/2 to
PS/2 the device name changes from "/dev/event1" to "/dev/event2" -- is
this intended?
If I do "echo -n 50 > resolution" "0xe8 0x01" is sent. I don't know if
this is correct for "usual" PS/2-devices but for
Folks,
I humbly submit configfs. With configfs, a configfs
config_item is created via an explicit userspace operation: mkdir(2).
It is destroyed via rmdir(2). The attributes appear at mkdir(2) time,
and can be read or modified via read(2) and write(2). readdir(3)
queries the list of item
On Sunday 03 April 2005 12:31 pm, [EMAIL PROTECTED] wrote:
> Okay, you obviously have easy access to usb development trees...
> Do you think you could just take this patch as a basis and fix
> remaining u32 vs pm-message-t in usb? --p
Fixing the "sparse -Wbitwise" messages, and addressing some o
On Sat, Apr 02, 2005 at 09:09:37AM +0300, Antti Salmela wrote:
> % mdadm --create -l 1 -n 2 /dev/md2 /dev/hde /dev/hdg
> % pvcreate /dev/md2
> % vgextend vg1 /dev/md2
> % pvmove /dev/hdf /dev/md2
A few similar reports still appearing, possibly still related to
the md bio_clone changes that fixed
On Sun, 3 Apr 2005, Dave Hansen wrote:
> On Sun, 2005-04-03 at 15:37 +0100, Mel Gorman wrote:
> > While testing the page placement policy patches on 2.6.12-rc1, I noticed
> > that aim9 is showing significant slowdowns on page allocation-related
> > tests. An excerpt of the results is at the end of
Jeremy Nickurak <[EMAIL PROTECTED]> writes:
> On Tue, 2005-03-08 at 21:52 +0100, Vojtech Pavlik wrote:
> > The problem is that the mouse really does reports all the double-button
> > stuff and autorepeat, and horizontal wheel together with button press on
> > wheel tilt.
>
> Okay, I'm playing wit
On Sun, 2005-04-03 at 21:23 +0200, Renate Meijer wrote:
> On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote:
>
> > Stephen Rothwell wrote:
> >
> >> On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> I've been working on a new DES implementation for Linux,
On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote:
> I humbly submit configfs. With configfs, a configfs
> ...
> Patch is against 2.6.12-rc1-bk3.
Updated for bk5 and the new backing_dev capabilites mask:
http://oss.oracle.com/~jlbec/files/configfs/2.6.12-rc1-bk5/con
On Sun, 3 Apr 2005 12:21:01 -0300
Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote:
> Em Sat, Apr 02, 2005 at 01:46:03PM -0600, James Bottomley escreveu:
> > Well, this is a brown paper bag for someone. The new protocol
>
> /me using such bag now :(
>
> Thanks a lot for the fix.
>
> David, P
Mathieu Bérard <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
> (Everyting run smoothly using 2.6.11-mm1)
> It seems to be related with mounting a reiserfs3 filesystem.
It looks more like an IDE bug.
> ReiserFS: hdg1: checking transaction
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote:
But is this not exactly what Dag Arne Osvik was trying to do ??
uint_fast32_t means that we want at least 32 bits but it's OK with
more if that happens to be faster on this particular architecture.
The problem was that the C99 standard types are n
On Sünndag 03 April 2005 20:50, Paul E. McKenney wrote:
> I couldn't find any way to suppress the "deprecated" warning that is
> generated by the "&sym" in the last line of the __EXPORT_SYMBOL()
> macro. Anyone know a way of doing this? There doesn't seem to me
> to be any point to giving the war
Ingo wrote:
> if_ there is a significant hierarchy between CPUs it
> should be represented via a matching sched-domains hierarchy,
Agreed.
I'll see how the sched domains hierarchy looks on a bigger SN2 systems.
If the CPU hierarchy is not reflected in the sched-domain hierarchy any
better there,
On Fre, 01 Apr 2005, Pavel Machek wrote:
> > I suspends fine, but never resumes. No CapsLock, no sysrq, no network is
> > working. Nothing in the log files. Is there anything which may cause
> > these troubles when compiled into the kernel and not loaded as module?
> > (as it was with my usb stuff
Andreas Schwab wrote:
Dag Arne Osvik <[EMAIL PROTECTED]> writes:
Yes, but wouldn't it be much better to avoid code like the following,
which may also be wrong (in terms of speed)?
#ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
#define fast_u32 u64
#else
#define fast_u32 u32
#endif
How ab
From: Steven Rostedt <[EMAIL PROTECTED]>
To: Jesper Juhl <[EMAIL PROTECTED]>
CC: Arun Srinivas <[EMAIL PROTECTED]>,LKML
Subject: Re: sched /HT processor
Date: Sun, 03 Apr 2005 11:31:03 -0400
On Sun, 2005-04-03 at 13:17 +0200, Jesper Juhl wrote:
>
> A reschedule can happen once every ms,
Thanks. yes, a reschedule may not take place after a ms, if the currently
running task cannot be preempted by another task.
(1) But, can a reschedule happen within a millisec (or once a process is
scheduled can schedule() be called before the next millisec.) ?
2) Also in case argument (1) is no
1 - 100 of 174 matches
Mail list logo
