Hello,
DG> Here's yet another batch of orinoco updates.
Will this patches be included in CVS-Head code? Now I checked and the
last modification of orinoco.c was about 4 days ago, when switch to
enable monitor mode on all firmwares was included...
DG> Smaller and less significant than the last,
Mark Williamson <[EMAIL PROTECTED]> writes:
> > The Xen guys idea of memory hotplug is another matter it sounds
> > like the want to page an OS with memory hotplug which is just
> > plain silly, and also unimplemented so I will cross that bridge
> > when I come to it.
>
> The idea isn't to page
Wiktor <[EMAIL PROTECTED]> wrote:
> furthermore, on many systems root may want to make users able to run
> some program with lowered nice, but not from root account and without
> having to know the root password... i've found a way to do this using
> shell scripts combined with suid bit and
On Fri, Mar 25, 2005 at 09:58:40AM -0500, Dmitry Torokhov wrote:
> I wonder why ALPS reconnect failed. You don't have a serial console
> set up, do you? If not then maybe you could make a huge framebuffer to
> capture as much info as you can... I hope you have a digital camera ;)
No serial ports
Andrew,
(As I decide how long to keep the paper bag on this time, here is an
updated patch. This one actually reduces the number of devices as well as
removes the device from the lists which makes things work better :)
Removed the FCC3 device from the lists of devices on MPC8555 & MPC8555E
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 Tue, Mar 29, 2005 at 01:42:26PM -0500, Dmitry Torokhov wrote:
> Could you please try the patch below - it should fix the issues you are
[snip]
> --- dtor.orig/drivers/input/serio/serio.c
> +++ dtor/drivers/input/serio/serio.c
> if (!serio->drv || !serio->drv->reconnect ||
>
Hello sir,
I successfully added linked list data structure
in kernel in header file. Write a C source file and
add it to kernel directory. then write 2 system calls
that read and write to linked list from user space
through that syscalls.
recompile kernel. Now able to
On Mon, Mar 28, 2005 at 07:57:52PM +0500, Ara Avanesyan wrote:
> Hi,
>
> I need some help on solving this strange problem.
> Here is what I have,
> I have a loadable module (linux.2.4.20) which contains a 2 mb static gloabal
> array.
> When I load it from linux booted via U-Boot the system
On Tue, Mar 29 2005, Bill Davidsen wrote:
> Jens Axboe wrote:
> >On Mon, Mar 28 2005, Chen, Kenneth W wrote:
> >
> >>The noop elevator is still too fat for db transaction processing
> >>workload. Since the db application already merged all blocks before
> >>sending it down, the I/O presented to
On Tue, 29 Mar 2005 22:05:30 PST, Paul Jackson wrote:
> gerrit wrote:
> > This is the core patch set for CKRM
>
> Welcome.
Hi Paul.
> Newcomers to CKRM might want to start reading these patches with "[patch
> 8/8] CKRM: Documentation". Starting with patch 0/8 or 1/8 will be
> difficult, at
Hi,
In my wlan driver module, i allocated some memory using kmalloc in
interrupt context, this one failed but its not returning NULL , so i was
proceeding further everything was going wrong... & finally the kernel
crahed. Can any one of you tell me why this is happening ? i cannot use
* Lee Revell <[EMAIL PROTECTED]> wrote:
> > could you run a bit with tracing disabled (in the .config) on the C3?
> > (but wakeup timing still enabled) It may very well be tracing overhead
> > that makes those latencies that high. Also, we'd thus have some hard
> > data on how much overhead
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> OK, I'm declaring defeat here. I've been fighting race conditions all
> day, and it's now 1 in the morning where I live. It looks like this
> implementation has no other choice but to have the waking up "pending
> owner" take the wait_list lock
On Tue, Mar 29, 2005 at 05:56:13PM -0500, Jeff Garzik wrote:
> It got a decent review, but from Christoph's list it looks like not all
> the issues raised during the review got addressed.
Exactly. Most reviews take more than one pass.
-
To unsubscribe from this list: send the line "unsubscribe
Guillaume wrote:
> I'm sorry but I really don't understand why you're speaking about
> accounting when I present results about fork connector. I agree that
> ELSA is using the fork connector but the fork connector has nothing to
> do with accounting.
True - sorry. I kinda hijacked your thread.
On Tue, Mar 29, 2005 at 01:47:34PM -0800, Andrew Morton wrote:
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > One more prematurely added drivers..
>
> This driver was first sent out for review a month ago, was upissued twice
> and generated over seventy linux-kernel emails including some
Christoph Lameter wrote:
The patch makes the following function calls available to allocate memory on
a specific node without changing the basic operation of the slab
allocator:
kmem_cache_alloc_node(kmem_cache_t *cachep, unsigned int flags, int node);
kmalloc_node(size_t size, unsigned int flags,
On Tue, 2005-03-29 at 22:06 -0800, dean gaudet wrote:
> On Tue, 29 Mar 2005, Jay Lan wrote:
>
> > The fork_connector is not designed to solve accounting data collection
> > problem.
> >
> > The accounting data collection must be done via a hook from do_exit().
>
> by the time do_exit() occurs
Guillaume wrote:
> When I wrote "several user space applications" it was just to say that
> this fork connector is not designed only for ELSA and fork information
> is available to every listeners.
So I suppose if fork_connector were not used to collect information for accounting, then someone
On Sat, 2005-03-26 at 11:04 -0500, Steven Rostedt wrote:
>
> On Fri, 25 Mar 2005, Esben Nielsen wrote:
> >
> > I like the idea of having the scheduler take care of it - it is a very
> > optimal coded queue-system after all. That will work on UP but not on SMP.
> > Having the unlock operation to
An updated MPU and noMMU support patch for ARM against linux 2.6.10 kernel
is available at :
http://opensrc.sec.samsung.com/download/linux-2.6.10-hsc1.patch.gz
You can select the memory management type "MPU" or "NONE" in the arm kernel
configuration menu, which was traditionally known as
On Tuesday 29 March 2005 14:49, Alexey Dobriyan wrote:
> On Tuesday 29 March 2005 23:02, Dmitry Torokhov wrote:
> > On Tue, 29 Mar 2005 21:28:20 +0400, Alexey Dobriyan <[EMAIL PROTECTED]>
> > wrote:
> > > On Tuesday 29 March 2005 10:27, Dmitry Torokhov wrote:
> > > > On Monday 28 March 2005
Dean wrote:
> by the time do_exit() occurs the parent may have disappeared
I don't think Jay was disagreeing with this. I think he agrees
that there is to be collected:
1) the classic bsd accounting data, in do_exit
2) the fork time by some mechanism at
fork time (perhaps just not the
On Tue, 29 Mar 2005 09:43:12 -0800, Randy.Dunlap <[EMAIL PROTECTED]> wrote:
> Yum Rayan wrote:
> > Attempt to reduce stack usage in module.c (linux-2.6.12-rc1-mm3).
> > Specifically from checkstack.pl
> >
> > Before patch
> > --
> > who_is_doing_it: 512
> > obsolete_params: 160
> >
Pekka writes:
> It is not a performance issue, it's an API issue.
> ...
> I am all for profiling but it should not stop us from merging the patches
Ok - sounds right.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul
On Wednesday 30 March 2005 05:27, Gerold Jury wrote:
>
> >> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
> >> > /*
> >> > * This looks horribly ugly, but the compiler can optimize it totally,
> >> > * as the count is constant.
> >> > */
> >> > static inline void *
Hi,
Paul Jackson writes:
Even such obvious changes as removing redundant checks doesn't
seem to ensure a performance improvement. Jesper Juhl posted
performance data for such changes in his microbenchmark a couple
of days ago.
It is not a performance issue, it's an API issue. Please note that
On Tuesday 29 March 2005 16:13, Romano Giannetti wrote:
> This is to report an issue with 2.6.11 and ACPI battery/ac. The resume is:
> acpi battery with preemptive kernel do not work, while the same kernel
> with no preempt works ok. I have tried to collect all the possible info;
> tell me if
On Tue, 29 Mar 2005, Jay Lan wrote:
> The fork_connector is not designed to solve accounting data collection
> problem.
>
> The accounting data collection must be done via a hook from do_exit().
by the time do_exit() occurs the parent may have disappeared... you do
need to record something at
gerrit wrote:
> This is the core patch set for CKRM
Welcome.
Newcomers to CKRM might want to start reading these patches with "[patch
8/8] CKRM: Documentation". Starting with patch 0/8 or 1/8 will be
difficult, at least if you're as dimm witted as I am.
Even the documentation included in
Antonio Vargas writes:
> Don't know exactly about power5, but G5 processor is described on IBM
> docs as doing automatic whole-page prefetch read-ahead when detecting
> linear accesses.
Sure, but linked lists would rarely be laid out linearly in memory.
Paul.
-
To unsubscribe from this list:
On Sun, 27 Mar 2005, Adam Belay wrote:
> Dynamic power management may require devices and drivers to transition
> between various physical and logical states. I would like to start a
> discussion on how these might be defined at the bus, driver, and class
> levels.
> Bus Level
> =
>
On Tuesday 29 March 2005 17:56, Rafael J. Wysocki wrote:
> Hi,
>
> There is a problem on my box (Asus L5D, x86-64 kernel) with the ACPI
> battery driver in the 2.6.12-rc1-mm[1-3] kernels. Namely, the battery
> monitor that I use (the kpowersave applet from SUSE 9.2) is no longer able
> to report
On Tuesday 29 March 2005 20:40, Dmitry Torokhov wrote:
>On Tuesday 29 March 2005 16:58, Michael Tokarev wrote:
>> Well, it's a matter of readability mostly. For now at least, when
>> char is always 8 bytes...
>
>Wow, that's one huge char you have there ;)
Yeah, I was gonna ask what language is
On Tue, 2005-03-29 at 07:35 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > I ran some test using the CBUS instead of the cn_netlink_send() routine
> > and the overhead is nearly 0%:
>
> Overhead of what? Does this include merging the data and getting it to
> disk?
I test the overhead of
This patch modifies the way pagesets in struct zone are allocated. It relocates
the pagesets contained in a zone for each cpu to the node that is nearest to
the cpu instead keeping the pagesets in the (possibly remote) target zone.
This means that the operations to manage caches of pages on remote
On Wed, 2005-03-30 at 03:48 +0200, Marcin Dalecki wrote:
> On 2005-03-30, at 01:39, Benjamin Herrenschmidt wrote:
> > Look at the pile of junk that are most winmodem driver implementations,
> > nothing I want to see in the kernel ever. Those things should be in
> > userland.
>
> You are joking?
On Tue, Mar 29, 2005 at 11:32:16PM -0500, John Richard Moser wrote:
> Does crossing a
> track boundary incur anything expensive?
AFAIK, yes. It's going to involve some kind of seeking (even a head
switch needs microjogging on modern drives), and it will certainly add
latency (although I don't
On Tue, 2005-03-29 at 07:23 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > The goal of the fork connector is to inform a user space application
> > that a fork occurs in the kernel. This information (cpu ID, parent PID
> > and child PID) can be used by several user space applications. It's
On Wed, 30 Mar 2005 13:55:25 +1000, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Serge E. Hallyn writes:
>
> > While investigating the inordinate performance impact one of my patches
> > seemed to be having, we tracked it down to two hlist_for_each_entry
> > loops, and finally to the prefetch
In article <[EMAIL PROTECTED]> you wrote:
> How likely is it that I can actually align stuff to 31.5KiB on the
> physical disk, i.e. have each block be a track?
It is not that easy to allign on tracks, even on raw partition. Some disks
have different length of tracks (of course because the inner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well then, the verdict is reached.
My original design is based around storing related data in the same
block so that the track cache allows me to evade doing reads while I
poke around.
The design will stay the same; but the dependency on the track
The patch makes the following function calls available to allocate memory on
a specific node without changing the basic operation of the slab
allocator:
kmem_cache_alloc_node(kmem_cache_t *cachep, unsigned int flags, int node);
kmalloc_node(size_t size, unsigned int flags, int node);
These are
On Sun, 2005-03-27 at 10:58 +0200, Ingo Molnar wrote:
> * Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > Running for several days with PREEMPT_DESKTOP, on the Athlon XP the
> > worst latency I am seeing is ~150 usecs! But on the C3 its about 4ms:
>
> could you run a bit with tracing disabled (in
On Wed, 2005-03-30 at 03:45 +0200, Marcin Dalecki wrote:
> > I think your misunderstanding is that you beliieve user-space can't do
> > RT. It's wrong. See JACK (jackit.sf.net), for example.
>
> I know JACK in and out. It doesn't provide what you claim.
Are you implying that "He don't know
John Richard Moser wrote:
How likely is it that I can actually align stuff to 31.5KiB on the
physical disk, i.e. have each block be a track?
I don't think this is very likely. Even being able to find out what the
physical disk arrangement is, or whether it is consistent in terms of
track size,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
How likely is it that I can actually align stuff to 31.5KiB on the
physical disk, i.e. have each block be a track?
Rather than leveraging the track cache, would it be less expensive for
me to simply read in blocks totaling about 16 or 32KiB all at
Done, updated patch w/comment sent to Andrew.
- kumar
On Mar 29, 2005, at 7:10 PM, Dan Malek wrote:
On Mar 29, 2005, at 5:30 PM, Kumar Gala wrote:
> Cleaned up irq_to_siubit array so we no longer need to do 1 <<
> (31-bit),
> just 1 << bit.
Will you please put a comment in here that indicates
Andrew,
(Updated this patch to include a comment at Dan Malek's request.)
Cleaned up irq_to_siubit array so we no longer need to do 1 << (31-bit),
just 1 << bit.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
diff -Nru a/arch/ppc/syslib/cpm2_pic.c b/arch/ppc/syslib/cpm2_pic.c
---
On Wed, 2005-03-30 at 03:45 +0200, Marcin Dalecki wrote:
> > I think your misunderstanding is that you beliieve user-space can't do
> > RT. It's wrong. See JACK (jackit.sf.net), for example.
>
> I know JACK in and out. It doesn't provide what you claim.
>
This was just an example, to prove
On Tuesday March 29, [EMAIL PROTECTED] wrote:
>
> Attached is the backout patch, for convenience.
Thanks. I had another look, and think I may be able to see the
problem. If I'm right, it is a problem with this patch.
> diff -Nru a/fs/jbd/commit.c b/fs/jbd/commit.c
> --- a/fs/jbd/commit.c
On Tue, Mar 29, 2005 at 06:44:18PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 29 Mar 2005, H. J. Lu wrote:
> >
> > > the smaller and faster version do not want to just rely on gas
> > > automatically getting it right, especially since gas has historically been
> > > very very bad at getting
Serge E. Hallyn writes:
> While investigating the inordinate performance impact one of my patches
> seemed to be having, we tracked it down to two hlist_for_each_entry
> loops, and finally to the prefetch instruction in the loop.
I would be interested to know what results you get if you leave
Remove the dump_recs debugging iwpriv command. It will be replaced
later with the simpler and more flexible get_rid command.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
===
---
Don't attempt to manually set the channel in infrastructure mode, the
firmware doesn't like that much. Also don't attempt to override the
firmware's default channel number for IBSS mode (I believe default
channel can vary by regulatory domain).
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Minor updates/bugfixes to the handling of wireless statistics.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/drivers/net/wireless/orinoco.c
===
--- working-2.6.orig/drivers/net/wireless/orinoco.c 2005-02-25
Consolidate allocation of firmware buffers. In the process, remove
duplication of a workaround for an old symbol firmware bug, and fix a
bug where we could retry the workaround, even if it already failed to
help.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index:
Adds an ignore_disconnect module parameter. When enabled, the driver
will continue attempting to send packets even when the firmware has
told us we've lost our link to the AP. On some firmwares this
substantially increases the usable range of the card (presumably
because we have an interrmittent
Hi Jeff, please apply:
Here's yet another batch of orinoco updates. Smaller and less
significant than the last, this is basically a handful of remaining
small updates before tackling the big changes (wext v15, monitor and
scanning). Patches are:
orinoco-wstats-updates
Hi,
While investigating the inordinate performance impact one of my patches
seemed to be having, we tracked it down to two hlist_for_each_entry
loops, and finally to the prefetch instruction in the loop.
The machine I'm testing on has 4 power5 1.5Ghz cpus and 16G ram. I was
mostly using dbench
Vicente Feito <[EMAIL PROTECTED]> writes:
> On Tuesday 29 March 2005 09:58 pm, you wrote:
>> Måns Rullgård wrote:
>> > "Ronald S. Bultje" <[EMAIL PROTECTED]> writes:
>> >>--- linux-2.6.5/drivers/media/video/zr36050.c.old 16 Sep 2004 22:53:27
>> >> - 1.2 +++
On Wed, Mar 30, 2005 at 04:07:39AM +0200, M?ns Rullg?rd wrote:
| Michael Tokarev <[EMAIL PROTECTED]> writes:
|
| > M?ns Rullg?rd wrote:
| >> "Ronald S. Bultje" <[EMAIL PROTECTED]> writes:
| >>
| >>>--- linux-2.6.5/drivers/media/video/zr36050.c.old 16 Sep 2004 22:53:27
- 1.2
| >>>+++
"Jean Delvare" <[EMAIL PROTECTED]> said:
[Sttributions missing, sorry]
> > > Think about it. If the pointer could be NULL, then it's unlikely that
> > > the bug would have gone unnoticed so far (unless the code is very
> > > recent). Coverity found 3 such bugs in one i2c driver [1], and the
>
This patch adds all current documentation on CKRM.
Signed-Off-By: Hubertus Franke <[EMAIL PROTECTED]>
Signed-Off-By: Chandra Seetharaman <[EMAIL PROTECTED]>
Signed-Off-By: Shailabh Nagar <[EMAIL PROTECTED]>
Signed-Off-By: Vivek Kashyap <[EMAIL PROTECTED]>
Signed-Off-By: Gerrit Huizenga <[EMAIL
This patch provides a resource controller for limiting the number
of tasks per class in CKRM.
Signed-Off-By: Chandra Seetharaman <[EMAIL PROTECTED]>
Signed-Off-By: Hubertus Franke <[EMAIL PROTECTED]>
Signed-Off-By: Shailabh Nagar <[EMAIL PROTECTED]>
Signed-Off-By: Gerrit Huizenga <[EMAIL
This patch provides the extensions for CKRM to track per socket classes.
This is the base to enable socket based resource control for inbound
connection control, bandwidth control etc.
Signed-Off-By: Vivek Kashyap <[EMAIL PROTECTED]>
Signed-Off-By: Gerrit Huizenga <[EMAIL PROTECTED]>
This patch provides the extensions for CKRM to track task classes.
This is the base to enable task class based resource control for
cpu, memory and disk I/O.
Signed-Off-By: Chandra Seetharaman <[EMAIL PROTECTED]>
Signed-Off-By: Hubertus Franke <[EMAIL PROTECTED]>
Signed-Off-By: Shailabh Nagar
Updates CKRM Resource Control Filesystem (rcfs) to include full
directory structure support.
Signed-Off-By: Chandra Seetharaman <[EMAIL PROTECTED]>
Signed-Off-By: Hubertus Franke <[EMAIL PROTECTED]>
Signed-Off-By: Shailabh Nagar <[EMAIL PROTECTED]>
Signed-Off-By: Vivek Kashyap <[EMAIL
Main code for CKRM default classification engine. Adds Resrouce
Control (rc) filesystem as mechanism for setting policies for
class assignments in CKRM.
Signed-Off-By: Chandra Seetharaman <[EMAIL PROTECTED]>
Signed-Off-By: Hubertus Franke <[EMAIL PROTECTED]>
Signed-Off-By: Shailabh Nagar
Core CKRM Event Callbacks.
On exec, fork, exit, real/effective gid/uid, use CKRM to associate
tasks with appropriate class.
Addressed all review comments except:
Greg KH:
Use of __bitwise and sparse in enum's
Use of kernel list type
Signed-off-by: Shailabh Nagar <[EMAIL
CKRM processor scheduling delay accounting - provides a mechanism
to In addition to counting frequency the total delay in ns is also
recorded. CPU delays are specified as cpu-wait and cpu-run. I/O delays
are recorded for memory and regular I/O. Information is accessible
through /proc//delay.
--
This is the core patch set for CKRM, review comments almost all
applied (there are a few we are still working on, mostly cosmetic).
However, this set has been extensively regression tested on IA32,
x86-64/EM64T, and PPC64, with various CKRM CONFIG options on and
off and both regression tests
On Tue, Mar 29, 2005 at 10:10:34AM +1000, Neil Brown wrote:
> On Monday March 28, [EMAIL PROTECTED] wrote:
> > On Mon, Mar 28, 2005 at 10:34:05AM +0300, [Ville Herva] wrote:
> > >
> > > I just upgraded from linux-2.4.21 + vserser 0.17 to 2.4.30rc3 + vserver
> > > 1.2.10. The box has been running
Pekka wrote:
> (4) The cleanups Jesper and others are doing are to remove the
> _redundant_ NULL checks (i.e. it is now checked twice).
Even such obvious changes as removing redundant checks doesn't
seem to ensure a performance improvement. Jesper Juhl posted
performance data for such
On Tue, 29 Mar 2005, H. J. Lu wrote:
>
> > the smaller and faster version do not want to just rely on gas
> > automatically getting it right, especially since gas has historically been
> > very very bad at getting things right.
>
> We are fixing those issues in assembler. If people run into
As long as the variable doesn't get overflowed you would have a negation, you
shouldn't do dri_data[5] = ptr->dri * 0xff; if ptr->dri it's 255, but if
ptr->dri = 1 i.e. (like is set in zr36050_setup) then you would be getting
the negation, -1. the Direct rendering support is a flag afaik, so in
On Wed, 2005-03-30 at 03:45 +0200, Marcin Dalecki wrote:
> On 2005-03-29, at 12:22, Takashi Iwai wrote:
> >
> > ALSA provides the "driver" feature in user-space because it's more
> > flexible, more efficient and safer than doing in kernel. It's
> > transparent from apps perspective. It really
Michael Tokarev <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>> "Ronald S. Bultje" <[EMAIL PROTECTED]> writes:
>>
>>>--- linux-2.6.5/drivers/media/video/zr36050.c.old16 Sep 2004 22:53:27
>>>- 1.2
>>>+++ linux-2.6.5/drivers/media/video/zr36050.c29 Mar 2005 20:30:23
Chen, Kenneth W wrote:
Nick Piggin wrote on Tuesday, March 29, 2005 5:32 PM
If it is doing a lot of mapping/unmapping (or fork/exit), then that
might explain why 2.6.11 is worse.
Fortunately there are more patches to improve this on the way.
Once benchmark reaches steady state, there is no
On Tue, Mar 29, 2005 at 04:30:01PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 28 Mar 2005, Andi Kleen wrote:
> >
> > "H. J. Lu" <[EMAIL PROTECTED]> writes:
> > > The new assembler will disallow them since those instructions with
> > > memory operand will only use the first 16bits. If the memory
On 2005-03-30, at 01:39, Benjamin Herrenschmidt wrote:
On Tue, 2005-03-29 at 17:25 -0600, Chris Friesen wrote:
Lee Revell wrote:
This is the exact line of reasoning that led to Winmodems.
My main issue with winmodems is not so much the software offload, but
rather that the vendors don't release
On 2005-03-30, at 00:13, Lee Revell wrote:
On Tue, 2005-03-29 at 11:22 +0200, Marcin Dalecki wrote:
No. You didn't get it. I'm taking the view that mixing sound is simply
a task you would typically love to make a DSP firmware do.
However providing a DSP for sound processing at 44kHZ on the same
On 2005-03-29, at 12:22, Takashi Iwai wrote:
ALSA provides the "driver" feature in user-space because it's more
flexible, more efficient and safer than doing in kernel. It's
transparent from apps perspective. It really doesn't matter whether
it's in kernel or user space.
Yes because it's that
On Tuesday 29 March 2005 16:58, Michael Tokarev wrote:
> Well, it's a matter of readability mostly. For now at least, when
> char is always 8 bytes...
Wow, that's one huge char you have there ;)
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Tue, 29 Mar 2005, Pavel Machek wrote:
> You insmod driver for your swap device, then you echo device numbers
> to /sys... then initiate resume.
So you're saying, let the machine come all the way up, log in as root,
"echo 8:5 > /sys/power/resume" (I think that was the name), then "echo
Nick Piggin wrote on Tuesday, March 29, 2005 5:32 PM
> If it is doing a lot of mapping/unmapping (or fork/exit), then that
> might explain why 2.6.11 is worse.
>
> Fortunately there are more patches to improve this on the way.
Once benchmark reaches steady state, there is no mapping/unmapping
Linus Torvalds wrote:
On Tue, 29 Mar 2005, Chen, Kenneth W wrote:
Linus Torvalds wrote on Tuesday, March 29, 2005 4:00 PM
The fact that it seems to fluctuate pretty wildly makes me wonder
how stable the numbers are.
I can't resist myself from bragging. The high point in the fluctuation
might be
>> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
>> > /*
>> > * This looks horribly ugly, but the compiler can optimize it totally,
>> > * as the count is constant.
>> > */
>> > static inline void * __constant_memcpy(void * to, const void * from,
>> > size_t n) {
>> >
On Mar 29, 2005, at 5:30 PM, Kumar Gala wrote:
Cleaned up irq_to_siubit array so we no longer need to do 1 <<
(31-bit),
just 1 << bit.
Will you please put a comment in here that indicates this array now
has this computation done? When I wrote it, these bit numbers
matched the registers and the
[ Hmmm .. the following pertains more to accounting than to fork_connector,
as have my other remarks earlier today. I notice just now I am on a thread
whose Subject is "fork_connector". Oh well. Sorry. - pj ]
Jay wrote:
> You probably can look at it this way: the accounting data
Hello,
Here is an additional patch to update m32r_sio driver.
This patch is against 2.6.12-rc1-mm3.
m32r_sio driver updates:
- Move m32r_sio specific description from asm-m32r/serial.h to
driver/serial/m32r_sio.c.
- Remove __register_m32r_sio, register_m32r_sio and unregister_m32r_sio
from
This patch is for fixing a build error of asm-m32r/spinlock.h
for CONFIG_DEBUG_SPINLOCK.
Please apply.
Thanks,
Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>
---
include/asm-m32r/spinlock.h |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff -ruNp
Nick Piggin wrote:
Jens Axboe wrote:
Looks good, I've been toying with something very similar for a long time
myself.
Here is another thing I just noticed that should further reduce the
locking by at least 1, sometimes 2 lock/unlock pairs per request.
At the cost of uglifying the code somewhat.
On Tue, 29 Mar 2005, Chen, Kenneth W wrote:
>
> Linus Torvalds wrote on Tuesday, March 29, 2005 4:00 PM
> > The fact that it seems to fluctuate pretty wildly makes me wonder
> > how stable the numbers are.
>
> I can't resist myself from bragging. The high point in the fluctuation
> might be
On Fri, 25 Mar 2005, Adrian Bunk wrote:
> Date: Fri, 25 Mar 2005 21:38:20 +0100
> From: Adrian Bunk <[EMAIL PROTECTED]>
> To: Roland Dreier <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], linux-net@vger.kernel.org,
> linux-kernel@vger.kernel.org
> Subject: Re: drivers/net/at1700.c:
Linus Torvalds wrote on Tuesday, March 29, 2005 4:00 PM
> The fact that it seems to fluctuate pretty wildly makes me wonder
> how stable the numbers are.
I can't resist myself from bragging. The high point in the fluctuation
might be because someone is working hard trying to make 2.6 kernel run
On Mon, 28 Mar 2005, Andi Kleen wrote:
>
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
> > The new assembler will disallow them since those instructions with
> > memory operand will only use the first 16bits. If the memory operand
> > is 16bit, you won't see any problems. But if the memory destinatin
Peter Chubb wrote:
"Chris" == Chris Friesen <[EMAIL PROTECTED]> writes:
Chris> Most cpus have some way of getting at a counter or decrementer
Chris> of various frequencies. Usually it requires low-level hardware
Chris> knowledge and often it needs assembly code.
As a device driver is inside the
On Mon, 28 Mar 2005, Chen, Kenneth W wrote:
> With that said, here goes our first data point along with some historical data
> we have collected so far.
>
> 2.6.11-13%
> 2.6.9 - 6%
> 2.6.8 -23%
> 2.6.2 - 1%
> baseline (rhel3)
Linus Torvalds wrote on Tuesday,
1 - 100 of 757 matches
Mail list logo
