Typo and tiny mistakes in comments of include/linux/poll.h.
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
--- include/linux/poll.h.orig 2007-02-13 10:25:43.0 +0800
+++ include/linux/poll.h2007-02-13 10:27:10.0 +0800
@@ -24,7 +24,7 @@
struct poll_table_struct;
/*
-
Style fix in fs/select.c.
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
--- fs/select.c.orig2007-02-13 12:42:37.0 +0800
+++ fs/select.c 2007-02-13 12:46:44.0 +0800
@@ -65,7 +65,7 @@ EXPORT_SYMBOL(poll_initwait);
static void free_poll_entry(struct poll_table_entry *entry)
Hi,
> I mean, all by-hand modifications must be in the $(srctree) (let's get
> this term), $(objtree) is output *only*. Thus, i would propose to remove
> it from the path. Even dynamic SCM mechanism of adding local version
> doesn't use `localversion' files.
I use localversion-$foo files in bot
So, my AMD Athlon XP2400+ with pata_pdc2027x, pata_sil680 and pata_via
survived four days of bonnie++, emerge -e world, dd if=//dev/random
of=/tmp/whatever, and most of all, four days of me :)
SO I guess it's safe to assume I didn't find any weird things by using
2.6.20 and the new libata drivers
> In my understanding, a "node" is a block of cpu, memory, devices.
> and there could be cpu-only-node, memory-only-node, device-only-node...
The trouble with this is that you'll need to harden large parts
of code against these. Especially a NULL pgdat is something quite
dangerous. You could mak
On Tuesday 13 February 2007 07:40, Arjan van de Ven wrote:
> On Mon, 2007-02-12 at 16:34 -0800, Christoph Lameter wrote:
> > On Fri, 2 Feb 2007, Andi Kleen wrote:
> >
> > > I've threatened to just disable RDTSC for ring 3 before, but it'll likely
> > > never happen because too many programs use it
Hi,
In the following document:
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html
The following is noted:
"The risk is that other hosts can probe for VIP using unicast packets
for which the hidden flag always replies. I'll continue to support the
hidden flag
for 2.4 and 2.6 t
On 2/12/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
The bigger problem is getting a file system that support it.
Andi,
It seems that the part that's not returning nanosecond is in the code
below. I've modified it, and now stat() is returning st_mtim.tv_nsec
correctly.
I've tested it on ex
On Tue, 13 Feb 2007 09:29:49 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > In my understanding, a "node" is a block of cpu, memory, devices.
> > and there could be cpu-only-node, memory-only-node, device-only-node...
>
> The trouble with this is that you'll need to harden large parts
> of co
On Tue, 2007-02-13 at 09:28 +0100, Andi Kleen wrote:
> On Tuesday 13 February 2007 07:40, Arjan van de Ven wrote:
> > On Mon, 2007-02-12 at 16:34 -0800, Christoph Lameter wrote:
> > > On Fri, 2 Feb 2007, Andi Kleen wrote:
> > >
> > > > I've threatened to just disable RDTSC for ring 3 before, but i
On Tue, 2007-02-13 at 16:38 +0800, Jeff Chua wrote:
> On 2/12/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > The bigger problem is getting a file system that support it.
>
>
> Andi,
>
> It seems that the part that's not returning nanosecond is in the code
> below. I've modified it, and now st
On 2/13/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
Hi,
while working on the last pieces of the file_ops constantification, DVB
is the small village in France that is holding the Romans at bay... but
I think I found the final flaw in it now:
*pdvbdev = dvbdev = kmalloc(sizeof(struct
> It seems that the part that's not returning nanosecond is in the code
> below. I've modified it, and now stat() is returning st_mtim.tv_nsec
> correctly.
>
> I've tested it on ext2 and reiserfs, and both seems to be working.
>
>
> I don't know why "t.tv_nsec = 0;" was set in the code. Any i
Eric W. Biederman wrote:
Nadia Derbey <[EMAIL PROTECTED]> writes:
I do not fully agree with you:
It is true that some ipc tunables play the role of DoS limits.
But IMHO the *mni ones (semmni, msgmni, shmmni) are used by the ipc subsystem to
adapt its data structures sizes to what is being aske
Christoph Lameter wrote:
> On Tue, 30 Jan 2007, Martin MOKREJS wrote:
>
>> Hi,
>> is this a known issue? Should I bother to upgrade to 2.6.19.2 if it
>> contains the fix?
>> Thank you any help. It might be related to NFS. The machine in question is
>> NFSv3 client,
>> udp. And used for computa
On 2/13/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
it was there to avoid the following situation:
on disk it's still in seconds
On 2/13/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
If you want ns resolution you need a file system that supports it:
that's currently XFS, JFS, NTFS/CIFS (reso
On Mon, 2007-02-12 at 21:35 -0800, Andrew Morton wrote:
>
> This looks hacky.
>
One other thing that could be added is a change in the initcalls .
ks0108 should be subsys_initcall() and the LCD devices
device_initcall(). That would make sure one runs before the other. I
don't think that alone w
Just a small issue with the latest kernel 2.6.20. When compiling make
menuconfig our ncurses library is not being detected. I currently use
2.6.15 with no problem and comparing the 2 I found a script (
scripts/kconfig/lxdialog/check-lxdialog.sh ) in the lxdialog directory
that checks for the nc
> If there is currently no way to provide this functionality using
> arp_ignore/arp_annonce/arp_filter or their friends, why is this still a
> patch
> And is not integrated into the mainline kernel?
eh? if you keep reading the doc it'll explain that there is arptables in
the current kernels, whic
Am Dienstag, 13. Februar 2007 00:31 schrieben Sie:
> Martin A. Fink wrote:
> > I have to store big amounts of data coming from 2 digital cameras to disk.
> > Thus I have to write blocks of around 1 MB at 30 to 50 frames per second
for
> > a long period of time. So it is important for me that the
On Tue, 2007-02-13 at 06:52 +0100, Nick Piggin wrote:
> Thanks for the confirmation.
>
> I'll obviously have to resend a new patchset because I made a silly
> paper-bag bug with this one. May I say that the s390 specific part of
> the change is acked-by: you?
Yes.
--
blue skies,
Martin.
Mart
(some of you might get this mail in double copy , sorry)
On 2/11/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:
Sorry for the delay.
Ditto!
It also seemed that my kernel compiling sk1llz had gone AWL, I
couldn't get the newly compiled kernel to run, until I realized the
initrd.img was mislink
Hi everybody,
I'm trying to fetch from the Linux kernel repository at
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/. After
downloading the objects, git failed while trying to fetch tags. Retrying the
fetch operation gives the following output:
$ git-fetch origin
Fetchi
Am Montag, 12. Februar 2007 20:08 schrieben Sie:
> On Mon, 12 Feb 2007 18:56:29 +0100
> "Martin A. Fink" <[EMAIL PROTECTED]> wrote:
>
> > I have to store big amounts of data coming from 2 digital cameras to disk.
> > Thus I have to write blocks of around 1 MB at 30 to 50 frames per second
for
>
Rafael J. Wysocki schrieb:
> I think we can introduce a "pm_safe" flag that will indicate if the driver
> handles suspend/resume correctly. If we do it, we can flag all of the drivers
> currently in the tree as "pm_safe" unless we know that they aren't. Next,
> we can convert the core to fail the
Pierre Ossman, le Tue 13 Feb 2007 06:47:41 +0100, a écrit :
> Sascha Sommer wrote:
> > I still consider this driver experimental, but without documentation this
> > is
> > probably not going to change anytime soon.
> > The question is now what I should do with the driver?
> > Is it worth to be in
On Tuesday 13 February 2007 08:52, Jan Beulich wrote:
> >Yup. How does this patch look to you? We set error_code and trap_no
> >for userspace faults and kernel faults which call die(). We don't set
> >them for kernelspace faults which are fixed up.
>
> Actually, after a second round of thinking
Geert Uytterhoeven schrieb:
> On Mon, 12 Feb 2007, Pavel Machek wrote:
>> > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL?
>> > It's nicer if you don't have to implement dummy functions at all.
>>
>> Unfortunately, drivers currently assume "NULL == nothing is needed",
Mor
> >
> The problem is: FreeBSD is fast, but lacks of some special drivers. Linux has
> all drivers but access to harddisk is unpredictable and thus unreliable!
> What can I do??
there's several tunables you can do;
1) increase /sys/block//queue/nr_requests
the linux default is on the low side
Nadia Derbey <[EMAIL PROTECTED]> writes:
> So, should I understand from this that automatic tuning and the AKT framework
> itself would make sense, given that I find the rigth tunables it should be
> applied to?
Sort of. The concept of things tuning themselves automatically makes
a lot of sense.
Andi Kleen wrote:
[EMAIL PROTECTED] writes:
+
+This feature aims at making the kernel automatically change the tunables
+values as it sees resources running out.
The only reason we have resource limit is to avoid DOS when one
resource consumes too much memory. When there is no such danger t
Martin A. Fink wrote:
> Am Dienstag, 13. Februar 2007 00:31 schrieben Sie:
>> Martin A. Fink wrote:
>>> I have to store big amounts of data coming from 2 digital cameras to disk.
>>> Thus I have to write blocks of around 1 MB at 30 to 50 frames per second
>>> for
>>> a long period of time. So it
On Feb 13 2007 09:52, Arjan van de Ven wrote:
>
>> If there is currently no way to provide this functionality using
>> arp_ignore/arp_annonce/arp_filter or their friends, why is this still a
>> patch
>> And is not integrated into the mainline kernel?
>
>eh? if you keep reading the doc it'll explai
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> > >
> > The problem is: FreeBSD is fast, but lacks of some special drivers. Linux
> > has
> > all drivers but access to harddisk is unpredictable and thus unreliable!
> > What can I do??
>
>
> there's several tunables you can do;
[...] Well Linu
On Tue, 2007-02-13 at 12:18 +0100, Andi Kleen wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> > > >
> > > The problem is: FreeBSD is fast, but lacks of some special drivers. Linux
> > > has
> > > all drivers but access to harddisk is unpredictable and thus unreliable!
> > > What can I
Am Dienstag, 13. Februar 2007 11:16 schrieben Sie:
> Martin A. Fink wrote:
> > Am Dienstag, 13. Februar 2007 00:31 schrieben Sie:
> >> Martin A. Fink wrote:
> >>> I have to store big amounts of data coming from 2 digital cameras to
disk.
> >>> Thus I have to write blocks of around 1 MB at 30 to 5
On Tue, 2007-02-13 at 18:42 +1100, Nick Piggin wrote:
> Joe Perches wrote:
[...]
> > perhaps:
> >
> > #define array_for_each(element, array) \
> > for ((element) = (array); \
> > (element) < ((array) + ARRAY_SIZE((array))); \
> > (element)++)
>
> If you're going for consiste
On Mon, 2007-02-12 at 23:39 -0800, Trond Myklebust wrote:
> commit 7c85d9007d05436e71d2b805b96c1e36a8193bd4
> Author: Trond Myklebust <[EMAIL PROTECTED]>
> Date: Wed Dec 13 15:23:48 2006 -0500
>
> NFS: Fixup some outdated comments...
>
> Signed-off-by: Trond Myklebust <[EMAIL PROTE
On Tuesday 13 February 2007 11:18, Nadia Derbey wrote:
> Andi Kleen wrote:
> > [EMAIL PROTECTED] writes:
> >
> >>+
> >>+This feature aims at making the kernel automatically change the tunables
> >>+values as it sees resources running out.
> >
> >
> > The only reason we have resource limit is to
Bernd Petrovitsch wrote:
On Tue, 2007-02-13 at 18:42 +1100, Nick Piggin wrote:
Joe Perches wrote:
[...]
perhaps:
#define array_for_each(element, array) \
for ((element) = (array); \
(element) < ((array) + ARRAY_SIZE((array))); \
(element)++)
If you're go
On Monday February 12, [EMAIL PROTECTED] wrote:
> >However
> >this "kernel BUG" is something newly introduced in 2.6.20 which should
> >be fixed in 2.6.20.1. Patch is below.
>
> I am using raid6. Am I at risk after applying this patch?
I'm not going to say "you are not at risk after applying thi
On Tue, Feb 13, 2007 at 09:52:39AM +0900, Ian Kent wrote:
> Indeed.
> Which kernel can you use?
> I believe that 2200 had another problem so can you use an fc5 kernel
> later than that?
I've ported your patch to 2257 (nothing special, only moved lines),
and it seems to work beautifully. I'm enlar
On Mon, 12 Feb 2007 23:26:42 -0800 (PST) Davide Libenzi
wrote:
>
> ARM-OABI also defines them, dunno why. Rmk?
I suspect that OABI stands for old ABI and the alignment of 64 bit
quantities changed at some point. I am pretty sure that arm is only
32bit, but I assume that they need backward compa
CC drivers/serial/8250_pci.o
drivers/serial/8250_pci.c: In function 'pciserial_resume_one':
drivers/serial/8250_pci.c:1830: warning: ignoring return value of
'pci_enable_device', declared with attribute warn_unused_result
This patch fixes it.
Signed-off-by: Stefano Brivio <[EMAIL PROTECTE
On Tue, Feb 13, 2007 at 11:30:10AM +0100, Stefano Brivio wrote:
> CC drivers/serial/8250_pci.o
> drivers/serial/8250_pci.c: In function 'pciserial_resume_one':
> drivers/serial/8250_pci.c:1830: warning: ignoring return value of
> 'pci_enable_device', declared with attribute warn_unused_resu
On Tue, 13 Feb 2007 11:30:10 +0100
Stefano Brivio <[EMAIL PROTECTED]> wrote:
> CC drivers/serial/8250_pci.o
> drivers/serial/8250_pci.c: In function 'pciserial_resume_one':
> drivers/serial/8250_pci.c:1830: warning: ignoring return value of
> 'pci_enable_device', declared with attribute wa
On Tue, 2007-02-13 at 21:54 +1100, Nick Piggin wrote:
> Bernd Petrovitsch wrote:
> > On Tue, 2007-02-13 at 18:42 +1100, Nick Piggin wrote:
> >
> >>Joe Perches wrote:
> >
> > [...]
> >
> >>>perhaps:
> >>>
> >>>#define array_for_each(element, array) \
> >>> for ((element) = (array); \
> >>>
> Well they do. The Flash disk I have (SATA-I) is capable of 48 MB/s and this
> value is reached over the whole disk size by windows as well as by FreeBSD.
> See my test results in the first thread.
Ok a flash disk should be more stable
> My Seagate Barracuda Harddisk drive (SATA-II) starts wit
From: Peter Oberparleiter <[EMAIL PROTECTED]>
debugfs: implement symbolic links
Implement a new function debugfs_create_symlink() which can be used
to create symbolic links in debugfs. This function can be useful
for people moving functionality from /proc to debugfs (e.g. the
gcov-kernel patch).
On 2/13/07, Marcel Siegert <[EMAIL PROTECTED]> wrote:
On Tuesday 13 February 2007, Arjan van de Ven wrote:
> Hi,
>
> while working on the last pieces of the file_ops constantification, DVB
> is the small village in France that is holding the Romans at bay... but
> I think I found the final flaw i
> there's several tunables you can do;
> 1) increase /sys/block//queue/nr_requests
>the linux default is on the low side
> 5) echo a larger value into /sys/block//queue/max_sectors_kb
>the default seems to be 512 which is... really low. The hw max is in
>another file in that directory;
Hi Laurent,
On Tue, 13 Feb 2007 10:29:59 +0100 Laurent Pinchart <[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> I'm trying to fetch from the Linux kernel repository at
> http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/. After
> downloading the objects, git failed while
Andi Kleen a écrit :
From: "Bryan O'Sullivan" <[EMAIL PROTECTED]>
This copy routine is memcpy-compatible, but on some architectures will use
cache-bypassing loads to avoid bringing the source data into the cache.
One case where this is useful is when a device issues a DMA to a memory
region, an
On Mon, 12 Feb 2007 12:38:15 -0500 (EST), Andrey Borzenkov wrote:
> Is not it too much fore a trivial two lines patch to a single file?
>
> {pts/1}% stg import
> ~/patch/Re_2_6_20_rc6_libata_PATA_ATAPI_CDROM_is_not_working.patch
> Importing
> patch "Re_2_6_20_rc6_libata_PATA_ATAPI_CDROM_is_not_wor
On Tuesday 13 February 2007, Arjan van de Ven wrote:
> Hi,
>
> while working on the last pieces of the file_ops constantification, DVB
> is the small village in France that is holding the Romans at bay... but
> I think I found the final flaw in it now:
>
>*pdvbdev = dvbdev = kmalloc(size
> attached find a patch that fixes the problem.
Hi,
Thank you for the quick response.
I think there is a small bug in this; at least I don't see where you
copy over the content of the fops template to the newly allocated piece
of memory...
Greetings,
Arjan van de Ven
--
if you want to mail
On Tue, Feb 13, 2007 at 03:14:23PM +0400, Manu Abraham wrote:
> >thanks for pointing out this issue.
> >
> >attached find a patch that fixes the problem.
> >
> >@mauro - please pull changeset a7ac92d208fe
> > dvbdev: fix illegal re-usage of fileoperations struct
> >
> >from http://www.linuxtv.or
albcamus napsal(a):
2007/2/12, Jiri Slaby <[EMAIL PROTECTED]>:
and lines from your boot loader.
title Fedora Core (2.6.20)
root (hd0,1)
kernel /vmlinuz-2.6.20 ro root=LABEL=/ vga=0x31B
initrd /initrd-2.6.20.img
And I have the SATA device /dev/sda3 labeled as '/'.
I would try to
Hi,
On Tuesday 13 February 2007 06:47, Pierre Ossman wrote:
> Sascha Sommer wrote:
> > I still consider this driver experimental, but without documentation this
> > is probably not going to change anytime soon.
> > The question is now what I should do with the driver?
> > Is it worth to be include
add format specifier %d for uid in ecryptfs_printk
Signed-off-by: Thomas Hisch <[EMAIL PROTECTED]>
---
fs/ecryptfs/messaging.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/ecryptfs/messaging.c b/fs/ecryptfs/messaging.c
index 47d7e7b..1674d33 100644
--- a/fs/ecrypt
Hi Ben,
On Mon, Feb 12, 2007 at 11:07:41AM +, Ben Dooks wrote:
> This is a new release of the SM501 MFD driver.
> +struct sm501_platdata_fbsub {
> + struct fb_mode *def_mode;
> + unsigned longmax_mem;
> + unsigned int flags;
> +};
This may be a ve
On Tuesday 13 February 2007, Jakub Jelinek wrote:
> On Tue, Feb 13, 2007 at 03:14:23PM +0400, Manu Abraham wrote:
> > >thanks for pointing out this issue.
> > >
> > >attached find a patch that fixes the problem.
> > >
> > >@mauro - please pull changeset a7ac92d208fe
> > > dvbdev: fix illegal re-u
On Tue, 13 February 2007 11:27:58 +, Alan wrote:
>
> isn't yet a heavily optimised libata path. Secondly erase block size
> matters with flash drives so the bigger each I/O the better erase block
> behaviour we should get.
Although that should max out somewhere between 16KiB and 128KiB,
depen
On Tue, 13 February 2007 11:29:18 +0100, Martin A. Fink wrote:
>
> Please Read Carefully! I talk about flash disk, not normal harddisks. There
> are no mechanical parts in flash disks, only flash memory. And therefore
> 48MB/s is excellent (compared to all other available disks)
>
> [...]
>
>
Hi!
> > Why do you think remounting filesystems is necessary? Are you getting
> > problems with some particular filesystem?
>
> No. But anything in a removable device neets to be either remounted
> read-only or unmounted if that is at all possible, because the user could
> unplug it. It is of c
Martin A. Fink wrote:
>> Also you have skipped the information how the images "arrive" on the system
> (PCI(e) card?), that may be important for an "end to end" view of the
> problem.
>
> Images arrive via Gigabit Ethernet. GigE Vision standard. (PCIe x4)
The the next question is: ChipSet/Used
Am Dienstag, 13. Februar 2007 12:25 schrieben Sie:
> > Well they do. The Flash disk I have (SATA-I) is capable of 48 MB/s and
this
> > value is reached over the whole disk size by windows as well as by
FreeBSD.
> > See my test results in the first thread.
>
> Ok a flash disk should be more sta
Linux please pull from
git://one.firstfloor.org/home/andi/git/linux-2.6
This is not all, but I pruned lots of stuff that still wasn't
quite ready. Less is more I guess.
Adrian Bunk:
i386: arch/i386/kernel/e820.c should #include
Alan:
i386: Fix Cyrix MediaGX detection
Alexey Do
Am Dienstag, 13. Februar 2007 13:24 schrieben Sie:
> Martin A. Fink wrote:
>
> >> Also you have skipped the information how the images "arrive" on the
system
> > (PCI(e) card?), that may be important for an "end to end" view of the
> > problem.
> >
> > Images arrive via Gigabit Ethernet. GigE
Micha³ Miros³aw wrote:
> get_*() don't need access to seq_file - iter_state is enough for them.
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.htm
Micha³ Miros³aw wrote:
> Eliminate possible NULL pointer dereference in nfulnl_recv_config().
>
> Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
>
> --- linux-2.6.20/net/netfilter/nfnetlink_log.c.10 2007-02-12
> 17:05:14.0 +0100
> +++ linux-2.6.20/net/netfilter/nfnetlink_log.c
Micha³ Miros³aw wrote:
> Fix reference counting (memory leak) problem in __nfulnl_send() and callers
> related to packet queueing.
>
> Signed-off-by: Michał Mirosław <[EMAIL PROTECTED]>
>
> --- linux-2.6.20/net/netfilter/nfnetlink_log.c.11 2007-02-12
> 17:35:50.0 +0100
> +++ linux-2.
On Tuesday 13 February 2007, you wrote:
>
> > attached find a patch that fixes the problem.
>
>
> Hi,
>
> Thank you for the quick response.
> I think there is a small bug in this; at least I don't see where you
> copy over the content of the fops template to the newly allocated piece
> of memor
On Tue, 13 Feb 2007, Jakub Jelinek wrote:
> Wouldn't it be better to kmalloc both struct dvb_device and
> struct file_operations together instead of doing 2 separate allocations?
> struct dvd_device_plus_fops
> {
> struct dvb_device dev;
> struct file_operations fops;
> } *dev_fops = kmalloc (s
On Tuesday 13 February 2007, Trent Piepho wrote:
> On Tue, 13 Feb 2007, Jakub Jelinek wrote:
> > Wouldn't it be better to kmalloc both struct dvb_device and
> > struct file_operations together instead of doing 2 separate allocations?
> > struct dvd_device_plus_fops
> > {
> > struct dvb_device dev
On 2/13/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
On Tue, 13 Feb 2007, Jakub Jelinek wrote:
> Wouldn't it be better to kmalloc both struct dvb_device and
> struct file_operations together instead of doing 2 separate allocations?
> struct dvd_device_plus_fops
> {
> struct dvb_device dev;
> s
On 2/13/07, Daniel Walker <[EMAIL PROTECTED]> wrote:
On Mon, 2007-02-12 at 21:35 -0800, Andrew Morton wrote:
>
> This looks hacky.
>
One other thing that could be added is a change in the initcalls .
ks0108 should be subsys_initcall() and the LCD devices
device_initcall(). That would make sure
Martin A. Fink wrote:
>> The needed total bandwidth may be to high and at least the incoming part via
> GigE may have serious overhead.
>> 150MB/s in via (at least 2) GigE, without Zero-Copy there is another 150MB/s
> memory to memory.
>> Then there is the next 150MB/s memory to the discs, withou
On Mon, Feb 12, 2007 at 08:22:01PM -0500, Dave Jones wrote:
> On Mon, Feb 12, 2007 at 10:39:25AM -0800, Venkatesh Pallipadi wrote:
> >
> > Introducing 'cpuidle', a new CPU power management infrastructure to manage
> > idle CPUs in a clean and efficient manner.
> > cpuidle separates out the dri
From: Ingo Molnar <[EMAIL PROTECTED]>
add include/linux/async.h which contains the kernel-side API
declarations.
it also provides NOP stubs for the !CONFIG_ASYNC_SUPPORT case.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
include/linux/as
From: Ingo Molnar <[EMAIL PROTECTED]>
add the kernel generic bits - these are present even if !CONFIG_ASYNC_SUPPORT.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
include/linux/sched.h |7 ++-
kernel/exit.c |3 +++
kern
From: Ingo Molnar <[EMAIL PROTECTED]>
Add Documentation/syslet-design.txt with a high-level description
of the syslet concepts.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
Documentation/syslet-design.txt | 137 ++
From: Ingo Molnar <[EMAIL PROTECTED]>
this adds the data structures used by the syslet / async system calls
infrastructure.
This is used only if CONFIG_ASYNC_SUPPORT is enabled.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
kernel/async.h
On Mon, Feb 12, 2007 at 01:53:03PM -0500, William Cohen wrote:
> After last week's experiment reducing size of task_struct on I was
> The is a signficant amount of space wasted for ext3_inode_cache. If
> the struct used for ext3_inode_cache struct could be made smaller,
> three objects rather than
From: Ingo Molnar <[EMAIL PROTECTED]>
wire up the new syslet / async system call syscalls and make it
thus available to user-space.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/i386/kernel/syscall_table.S |5 +
include/asm-i3
From: Ingo Molnar <[EMAIL PROTECTED]>
the core syslet / async system calls infrastructure code.
Is built only if CONFIG_ASYNC_SUPPORT is enabled.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
kernel/Makefile |1
kernel/async.c | 81
I'm pleased to announce the first release of the "Syslet" kernel feature
and kernel subsystem, which provides generic asynchrous system call
support:
http://redhat.com/~mingo/syslet-patches/
Syslets are small, simple, lightweight programs (consisting of
system-calls, 'atoms') that the kerne
From: Ingo Molnar <[EMAIL PROTECTED]>
enable CONFIG_ASYNC_SUPPORT on x86.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/i386/Kconfig |4
1 file changed, 4 insertions(+)
Index: linux/arch/i386/Kconfig
From: Ingo Molnar <[EMAIL PROTECTED]>
provide an optimized assembly version of sys_umem_add().
It is about 2 times faster than the C version.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/i386/lib/getuser.S | 27
From: Ingo Molnar <[EMAIL PROTECTED]>
add include/linux/syslet.h which contains the user-space API/ABI
declarations. Add the new header to include/linux/Kbuild as well.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
include/linux/Kbuild |
From: Ingo Molnar <[EMAIL PROTECTED]>
add the create_async_thread() way of creating kernel threads:
these threads first execute a kernel function and when they
return from it they execute user-space.
An architecture must implement this interface before it can turn
CONFIG_ASYNC_SUPPORT on.
Signed
From: Ingo Molnar <[EMAIL PROTECTED]>
provide an optimized assembly version of the copy_uatom() method.
This is about 3 times faster than the C version.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/i386/lib/getuser.S | 115 +
Hi Leopold,
Le Lundi 12 Février 2007 17:23, Leopold Palomo-Avellaneda a écrit :
> A Dilluns 12 Febrer 2007 10:11, Jean Delvare va escriure:
> > Did you report the problem to Asus? They should fix it. Maybe this new
> > BIOS actually fixes some other problems you have.
>
> no. It's on the todo list
On Mon, Feb 12, 2007 at 01:36:34PM -0800, Roland McGrath wrote:
> > 2. The following proggie renders box unusable in ~10 seconds (but not
> >mainline kernel where Ctrl+C will kill process).
>
> I haven't been able to reproduce this so far on my test machine. I got
> bored after about 10 minute
On Tue, Feb 13, 2007 at 01:15:18PM +1100, Rusty Russell wrote:
>
> Good spotting! This function needs to be passed skb_headlen(skb),
> rather than skb->len. Patch is below (I renamed the parameter as well,
> for clarity).
How about just dropping that parameter and using skb_headlen(skb)
directl
On Tue, 2007-02-13 at 09:50 +0100, Olivier Galibert wrote:
> On Tue, Feb 13, 2007 at 09:52:39AM +0900, Ian Kent wrote:
> > Indeed.
> > Which kernel can you use?
> > I believe that 2200 had another problem so can you use an fc5 kernel
> > later than that?
>
> I've ported your patch to 2257 (nothing
Olivier Galibert wrote:
> On Tue, Feb 13, 2007 at 09:52:39AM +0900, Ian Kent wrote:
>> Indeed.
>> Which kernel can you use?
>> I believe that 2200 had another problem so can you use an fc5 kernel
>> later than that?
>
> I've ported your patch to 2257 (nothing special, only moved lines),
> and it s
On Tue, Feb 13, 2007 at 11:18:57AM +0530, Srivatsa Vaddagiri wrote:
> Which make me wonder why we need task_lock() at all ..I can understand
> the need for a lock like that if we are reading/updating multiple words
> in task_struct under the lock. In this case, it is used to read/write
> just one p
[EMAIL PROTECTED] wrote:
> This patch implements the BeanCounter resource control abstraction
> over generic process containers. It contains the beancounter core
> code, plus the numfiles resource counter. It doesn't currently contain
> any of the memory tracking code or the code for switching bean
On 2/13/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> This patch implements the BeanCounter resource control abstraction
> over generic process containers. It contains the beancounter core
> code, plus the numfiles resource counter. It doesn't currently contain
> any o
1 - 100 of 418 matches
Mail list logo
