On Wed, 28 Feb 2007 15:14:20 -0800, David Brownell wrote:
> The writing on the wall seem to be that the parport stack is orphaned,
> rather than maintained by four folk ... and having a webpage that says
> the latest patches are based on a 2.5 kernel.
I share David's impression here. Andrew, can y
On Thu, 1 Mar 2007 00:54:32 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> Since freezable workqueues are broken in 2.6.21-rc
> (cf. http://marc.theaimsgroup.com/?l=linux-kernel&m=116855740612755,
> http://marc.theaimsgroup.com/?l=linux-kernel&m=117261312523921&w=2)
> it's better to change
On Wed, 28 Feb 2007 22:23:41 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> > That all looks rather deliberate.
> >
> > > powerpc/kernel/process.c: t->flags ^= (_TIF_ABI_PENDING |
> > > _TIF_32BIT);
> > >
> > > ia64/kernel/mca.c: ti->flags = _TIF_MCA_INIT;
> > >
> > > a
On Wed, Feb 28, 2007 at 04:14:14PM +, Pavel Machek ([EMAIL PROTECTED])
wrote:
> Hi!
>
> > > I think what you are not hearing, and what everyone else is saying
> > > (INCLUDING Linus), is that for most programmers, state machines are
> > > much, much harder to program, understand, and debug co
Currently sm501fb_crtsrc_store() won't allow the routing to be changed
via echos from userspace in to the sysfs file. The reason for this is
that the strnicmp() for both heads uses a sizeof() for the string length,
which ends up being strlen() + 1 (\0 in the normal case, but the echo
gives a newlin
On Thu, 1 Mar 2007 14:56:40 +1100 [EMAIL PROTECTED] (Tony Breeds) wrote:
> From: Tony Breeds <[EMAIL PROTECTED]>
>
> Fix soft lockup with iSeries viocd driver, caused by eventually calling
> end_that_request_first() with nr_bytes 0.
>
> The lockup is triggered by hald, interrogating the device.
On Wed, Feb 28, 2007 at 11:42:24AM -0800, Davide Libenzi
(davidel@xmailserver.org) wrote:
> On Wed, 28 Feb 2007, Chris Friesen wrote:
>
> > Davide Libenzi wrote:
> >
> > > struct async_syscall {
> > > unsigned long nr_sysc;
> > > unsigned long params[8];
> > > long *result;
> > > };
> > >
On Thu, 1 Mar 2007 00:37:48 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Thu, 1 Mar 2007 14:56:40 +1100 [EMAIL PROTECTED] (Tony Breeds) wrote:
>
> > From: Tony Breeds <[EMAIL PROTECTED]>
> >
> > Fix soft lockup with iSeries viocd driver, caused by eventually calling
> > end_that_request_fi
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> I see no real difference between the two assertions. Nice is just a
> mechanism to set priority, so I applied your assertion to a different
> range of priorities than nice covers, and returned it to show that the
> code contradicts itself. It can
On Thu, 01 Mar 2007 12:15:29 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> +/* check if the mac in reg is valid */
> +#define SMC_GET_MAC_ADDR(addr) \
> + do {\
> + unsigned int __v;
On Tue, 2007-02-27 at 10:25 +0100, Mike Galbraith wrote:
> On Sun, 2007-02-25 at 09:32 +0100, Mike Galbraith wrote:
>
> > Fix NULL pointer dereference in cmos_rtc registration failure path.
> >
> > Signed-off-by: Mike Galbraith <[EMAIL PROTECTED]>
> >
> > diff --git a/drivers/rtc/class.c b/drive
On 24/02/07 15:19, Simon Arlott wrote:
> I've modified the driver of an USB device (cxacru) to schedule the next poll
> for status every 1s using round_jiffies_relative instead of just waiting 1s
> since the last poll was completed. This process takes on average 11ms to
> complete and while it is w
Hi!
> > Since freezable workqueues are broken in 2.6.21-rc
> > (cf. http://marc.theaimsgroup.com/?l=linux-kernel&m=116855740612755,
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=117261312523921&w=2)
> > it's better to change the only user of them, which is XFS, to use "normal"
> > nonfreezabl
On Thu, Mar 01, 2007 at 12:15:46PM +0800, Wu, Bryan wrote:
> +#define stamp(fmt, args...) pr_debug("%s:%i: " fmt "\n", __FUNCTION__,
> __LINE__, ## args)
> +#define stampit() stamp("here i am")
> +
Are these really necessary for the final driver? It's littered all over
the place, and presumably t
On Thu, Mar 01, 2007 at 05:24:56PM +0900, Paul Mundt wrote:
> Currently sm501fb_crtsrc_store() won't allow the routing to be changed
> via echos from userspace in to the sysfs file. The reason for this is
> that the strnicmp() for both heads uses a sizeof() for the string length,
> which ends up be
On Thu, Mar 01, 2007 at 02:33:01AM +0100, Andrea Arcangeli ([EMAIL PROTECTED])
wrote:
> On Thu, Mar 01, 2007 at 12:12:28AM +0100, Ingo Molnar wrote:
> > more capable by providing more special system calls like sys_upcall() to
> > execute a user-space function. (that way a syslet could still execu
On 26/02/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
I have a webserver running a rather old 2.6.13.4 kernel that a few
minutes ago surprised me by logging the following message :
kernel: nfs_update_inode: inode 309229856 mode changed, 0100644 to 0040755
I just got one more of these (well, sli
On Thu, 2007-03-01 at 00:54 -0800, Andrew Morton wrote:
> On Thu, 01 Mar 2007 12:15:29 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
>
> > +/* check if the mac in reg is valid */
> > +#define SMC_GET_MAC_ADDR(addr) \
> > + do {
* Kevin O'Connor <[EMAIL PROTECTED]> wrote:
> I'd like to propose a simpler userspace API for syslets. I believe
> this revised API is just as capable as yours (anything done purely in
> kernel space with the existing API can also be done with this one).
>
> An "atom" would look like:
>
> st
Hi!
> > > I understand that - and I totally agree.
> > > But when more complex, more bug-prone code results in higher performance
> > > - that must be used. We have linked lists and binary trees - the latter
> >
> > No-o. Kernel is not designed like that.
> >
> > Often, more complex and slightly
On Thu, 1 Mar 2007 10:15:21 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > - xfslogd_workqueue = create_freezeable_workqueue("xfslogd");
> > > + xfslogd_workqueue = create_workqueue("xfslogd");
> > > if (!xfslogd_workqueue)
> > > goto out_free_buf_zone;
> > >
> > > - xfsdatad_wo
On Thu, Mar 01, 2007 at 11:38:06AM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> > struct async_syscall {
> > long *result;
> > unsigned long asynid;
> > unsigned long nr_sysc;
> > unsigned long params[8];
> > };
>
> Having result pointer as NULL might imply that result is
On Thu, 01 Mar 2007 17:23:23 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-03-01 at 00:54 -0800, Andrew Morton wrote:
> > On Thu, 01 Mar 2007 12:15:29 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> >
> > > +/* check if the mac in reg is valid */
> > > +#define SMC_GET_MAC_ADDR(addr)
[trimming cc list since I'm only replying to the avr32 part]
On Wed, 28 Feb 2007 22:03:49 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers <[EMAIL PROTECTED]>
> wrote:
> > avr32/kernel/ptrace.c: ti->flags |= _TIF_BREAKPOINT;
>
> No,
On Wed, 28 Feb 2007 22:39:38 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> - 32-bit user-space on 64-bit kernel compat support. 32-bit syslet and
>threadlet binaries work fine on 64-bit kernels.
Yay! :-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auu
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
to bisect this.
Ingo
-
To unsubscribe fr
On Thu, 1 Mar 2007 10:34:51 +0100 Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> > On Mon, 26 Feb 2007 12:10:37 -0800 Mathieu Desnoyers <[EMAIL PROTECTED]>
> > wrote:
>
> > > avr32/kernel/ptrace.c: ti->flags |= _TIF_BREAKPOINT;
> >
> > No, I don't immediately see anything in the flush
On Thu, Mar 01, 2007 at 10:26:34AM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
> > > 10% gain in speed is NOT worth major complexity increase.
> >
> > Should I create a patch to remove rb-tree implementation?
>
> If you can replace them with something simpler, and no worse than 10%
> slower i
On Thu, 01 Mar 2007 08:35:28 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > > This deadlock happens, when dirty pages from one filesystem are
> > > written back through another filesystem. It easiest to demonstrate
> > > with fuse although it could affect looback mounts as well (see
> > > fo
> > > > This deadlock happens, when dirty pages from one filesystem are
> > > > written back through another filesystem. It easiest to demonstrate
> > > > with fuse although it could affect looback mounts as well (see
> > > > following patches).
> > > >
> > > > Let's call the filesystems A(bove)
On Thu, 01 Mar 2007 09:37:06 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > Sigh. What's this about i_mutex? That appears to be some critical
> > information which _still_ isn't being communicated.
> >
>
> This:
>
> ssize_t generic_file_aio_write(struct kiocb *iocb, const struct iovec *i
On Thu, 01 Mar 2007 12:15:14 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> Here is the blackfin on-chip ethernet MAC controller driver for Linux.
>
> It's name is blackfin-driver-net-stamp537.patch
>
> [PATCH] Blackfin: on-chip ethernet MAC controller driver
>
> This patch imple
> I'm just not going to apply weird hacks to work around a bug which
> I do not understand, and I have spent way too much time trying to understand
> this one.
I suggest you apply patch #5 "balance dirty pages from loop device"
and see for yourself the same deadlock with a simple loopback mount.
On Thu, 2007-03-01 at 13:29 +0530, Vivek Goyal wrote:
> On Thu, Mar 01, 2007 at 04:16:59PM +0900, Fernando Luis Vázquez Cao wrote:
> > Use the APIC to determine the hardware processor id when APIC support
> > has been selected, independently of whether CONFIG_SMP is set or not.
> >
> > Signed-off-
On Thu, Mar 01, 2007 at 04:18:23PM +0900, Fernando Luis Vázquez Cao wrote:
> Move definition of hard_smp_processor_id to asm/smp.h on alpha, m32r,
> powerpc, s390, sparc, sparc64, and um architectures.
>
> Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]>
> ---
>
> diff -urNp linux-2.6
On Thu, 2007-03-01 at 01:32 -0800, Andrew Morton wrote:
> On Thu, 01 Mar 2007 17:23:23 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-03-01 at 00:54 -0800, Andrew Morton wrote:
> > > On Thu, 01 Mar 2007 12:15:29 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> > >
> > > > +/* check
oh, and please consider removing all the CVS control strings from the
blackfin code. Because they become meaningless once the code is
merged into mainline.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> I posted kevent/epoll benchmarks and related design issues too many
> times both with handmade applications (which might be broken as hell)
> and popular open-source servers to repeat them again.
numbers are crutial here - and given the epoll bug
Here is the latest revision of the anti-fragmentation patches. Of
particular note in this version is special treatment of high-order atomic
allocations. Care is taken to group them together and avoid grouping pages
of other types near them. Artifical tests imply that it works. I'm trying to
get the
The fragmentation reduction strategy needs to track if pages within a block
can be moved or reclaimed so that pages are freed to the appropriate list.
This patch adds a bitmap for flags affecting a whole a MAX_ORDER block
of pages.
In non-SPARSEMEM configurations, the bitmap is stored in the stru
It is often known at allocation time whether a page may be migrated or
not. This patch adds a flag called __GFP_MOVABLE and a new mask called
GFP_HIGH_MOVABLE. Allocations using the __GFP_MOVABLE can be either migrated
using the page migration mechanism or reclaimed by syncing with backing
storage
This patch flags the allocations from low memory that may be migrated.
A GFP_USER_MOVABLE similar to GFP_HIGH_MOVABLE is not provided in this patch
because it would only be used once. This patch uses __GFP_MOVABLE twice
for a GFP_USER and a GFP_NOIO allocation. There is little point defining
GFP
This patch adds the core of the fragmentation reduction strategy. It
works by grouping pages together based on their ability to migrate or be
reclaimed. Basically, it works by breaking the list in zone->free_area list
into MIGRATE_TYPES number of lists.
Signed-off-by: Mel Gorman <[EMAIL PROTECTE
On Thu, 01 Mar 2007 17:52:48 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> > Please always prefer coding in C over coding in cpp.
>
> Yes, it can be writen as a C function.
> We just follow other implementation in the drivers/net/smc91x.h
>
> start at line 1156 of
> ---
> #ifndef SMC_GET_MAC_AD
The freelists for each migrate type can slowly become polluted due to the
per-cpu list. Consider what happens when the following happens
1. A 2^(MAX_ORDER-1) list is reserved for __GFP_MOVABLE pages
2. An order-0 page is allocated from the newly reserved block
3. The page is freed and placed on t
The grouping mechanism has some memory overhead and a more complex allocation
path. This patch allows the strategy to be disabled for small memory systems
or if it is known the workload is suffering because of the strategy. It also
acts to show where the page groupings strategy interacts with the
Per-cpu pages can accidentally cause fragmentation because they are free, but
pinned pages in an otherwise contiguous block. When this patch is applied,
the per-cpu caches are drained after the direct-reclaim is entered if the
requested order is greater than 0. It simply reuses the code used by s
This patch marks a number of allocations that are either short-lived such as
network buffers or are reclaimable such as inode allocations. When something
like updatedb is called, long-lived and unmovable kernel allocations tend
to be spread throughout the address space which increases fragmentatio
When a fallback occurs, there will be free pages for one allocation type
stored on the list for another. When a large steal occurs, this patch will
move all the free pages within one list to the other.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
page_alloc.c | 65 +++
This patch chooses blocks with lower PFNs when placing kernel allocations. This
is particularly important during fallback in low memory situations to stop
unmovable pages being placed throughout the entire address space.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
page_alloc.c | 20
In rare cases, the kernel needs to allocate a high-order block of pages
without sleeping. For example, this is the case with e1000 cards configured
to use jumbo frames. Migrating or reclaiming pages in this situation is
not an option.
This patch groups these allocations together as much as possi
MIGRATE_RECLAIMABLE allocations tend to be very bursty in nature like
when updatedb starts. It is likely this will occur in situations where
MAX_ORDER blocks of pages are not free. This means that updatedb can scatter
MIGRATE_RECLAIMABLE pages throughout the address space. This patch is more
agres
Changelog since v1
o Rebased to 2.6.20-rc6-mm2
o Added necessary changes to per-zone VM stats for new zone (Christoph)
o Removed unnecessary changes to __ZONE_SHIFT (Christoph)
o Added paranoid check for overflow in cmdline_parse_kernelcore (Andy)
The following 8 patches against 2.6.20-mm2 create
(Note, this is identical to the equivilant patch in list-based
anti-fragmentation. When applying both sets of patches, only apply this once)
It is often known at allocation time when a page may be migrated or
not. This patch adds a flag called __GFP_MOVABLE and a new mask called
GFP_HIGH_MOVABLE.
This patch creates an additional zone, ZONE_MOVABLE. This zone is only
usable by allocations which specify both __GFP_HIGHMEM and __GFP_MOVABLE.
Hot-added memory continues to be placed in their existing destination as
there is no mechanism to redirect them to a specific zone.
Signed-off-by: Mel
Huge pages are not movable so are not allocated from ZONE_MOVABLE. However,
as ZONE_MOVABLE will always have pages that can be migrated or reclaimed,
it can be used to satisfy hugepage allocations even when the system has been
running a long time. This allows an administrator to resize the hugepag
This patch adds the kernelcore= parameter for x86.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
setup.c |1 +
1 files changed, 1 insertion(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.20-mm2-003_mark_hugepages_movable/arch/i386/kernel/setup.c
linux-2.6.20-mm2-004_x8
This patch adds the kernelcore= parameter for ppc and powerpc.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
powerpc/kernel/prom.c |1 +
ppc/mm/init.c |2 ++
2 files changed, 3 insertions(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.20-mm2-004_x86_set_kern
This patch adds the kernelcore= parameter for x86_64.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
e820.c |1 +
1 files changed, 1 insertion(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.20-mm2-005_ppc64_set_kernelcore/arch/x86_64/kernel/e820.c
linux-2.6.20-mm2-006_x
This patch adds the kernelcore= parameter for ia64.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
efi.c |3 +++
1 files changed, 3 insertions(+)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.20-mm2-006_x8664_set_kernelcore/arch/ia64/kernel/efi.c
linux-2.6.20-mm2-007_ia64
Once all patches are applied, a new command-line parameter exist and a new
sysctl. This patch adds the necessary documentation.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
filesystems/proc.txt | 15 +++
kernel-parameters.txt | 16
sysctl/vm.txt |
Hi!
> > > > 10% gain in speed is NOT worth major complexity increase.
> > >
> > > Should I create a patch to remove rb-tree implementation?
> >
> > If you can replace them with something simpler, and no worse than 10%
> > slower in worst case, then go ahead. (We actually tried to do that at
> >
Hi all,
I've posted up patches that implement the two generally accepted approaches
for reducing external fragmentation in the buddy allocator. The first
(list-based) works by grouping pages of related mobility together, across
all existing zones. The second (zone-based) creates a zone where only
On Thu, 1 Mar 2007 01:45:23 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> If there's a lesson here, it is "don't provide #defines in the header for
> both versions".
Yes, that's true. It looks like all the other arches do the same thing
with the _TIF flags, however, so just ripping it out prob
On Thu, 2007-03-01 at 02:03 -0800, Andrew Morton wrote:
> On Thu, 01 Mar 2007 17:52:48 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
>
> > > Please always prefer coding in C over coding in cpp.
> >
> > Yes, it can be writen as a C function.
> > We just follow other implementation in the drivers/ne
Hi!
> > But it is true that for most kernel programmers, threaded
> > programming is much easier to understand, and we need to engineer the
> > kernel for what will be maintainable for the majority of the kernel
> > development community.
>
> What's probably true is that, for a kernel to stay com
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Threadlets behave much worse without event driven model, events can
> > behave worse without backed threads, they are mutually compensating.
>
> I think Ingo demonstrated unoptimized threadlets to be within 5% to
> the speed of kevent. [...]
that
On Thu, Mar 01, 2007 at 10:44:24AM +1100, David Gibson wrote:
> On Wed, Feb 28, 2007 at 10:26:30PM +, Russell King wrote:
> > On Tue, Feb 20, 2007 at 02:19:51PM +1100, David Gibson wrote:
> > > Therefore, this patch defines a UPF_FIXED_PORT flag for the uart_port
> > > structure. If this flag
* Bernhard Walle <[EMAIL PROTECTED]> [2007-03-01 01:11]:
> * Jan Kiszka <[EMAIL PROTECTED]> [2007-03-01 00:22]:
> > Robin Getz wrote:
> > > Does anyone have a pointer for a MOST (Media Oriented Systems Transport)
> > > driver?
> > >
> > > http://en.wikipedia.org/wiki/Media_Oriented_Systems_Transp
This patch contains the following possible cleanups:
- every file should #include the headers containing the prototypes for
it's global functions
- the xen_set_pud() prototype mismatch gcc was now able to detect
is corrected
- make the following needlessly global variable static:
- events
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and
> 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt
> to bisect this.
hm. There's some weird bisection artifact here. Here are the commits i
tested, in git-lo
* Bernhard Walle <[EMAIL PROTECTED]> [2007-03-01 01:11]:
> PS: SUSE has nothing to do with that driver, I only write with my SUSE
> address because I don't want to re-subscribe because of one mail.
Interesting, because it was addressed to my gmx address in CC, Mutt
automatically choosed my gmx add
Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - every file should #include the headers containing the prototypes for
> it's global functions
> - the xen_set_pud() prototype mismatch gcc was now able to detect
> is corrected
> - make the following needlessly glo
On Wed, 2007-02-28 at 16:55 +, James Simmons wrote:
> So the problem is not the configuration but that for some reason the
> backlight state is set to off by default.
Maybe, maybe not. I'm not sure there's been enough information to
conclude that.
At the moment, I'd like a patch which makes
On Thu, Mar 01, 2007 at 10:54:02AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > I posted kevent/epoll benchmarks and related design issues too many
> > times both with handmade applications (which might be broken as hell)
> > and popular
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> I've just re-run tests on my amd64 test machine without debug options:
>
> epoll4794.23
> kevent 6468.95
could you please post the two URLs for the exact evserver code used for
these measurements? (even if you did so already in the
On Thursday 01 March 2007 11:59, Evgeniy Polyakov wrote:
> Yes, it is about 98-100% in both cases.
> I've just re-run tests on my amd64 test machine without debug options:
>
> epoll 4794.23
> kevent6468.95
>
It would be valuable if you could post oprofile results (CPU_CLK_
On Thursday 01 March 2007 19:46, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > I see no real difference between the two assertions. Nice is just a
> > mechanism to set priority, so I applied your assertion to a different
> > range of priorities than nice covers, and returned
On Thu, Mar 01, 2007 at 12:00:22PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > I've just re-run tests on my amd64 test machine without debug options:
> >
> > epoll4794.23
> > kevent 6468.95
>
> could you please post the two
On Thu, Mar 01, 2007 at 11:11:02AM +0100, Pavel Machek ([EMAIL PROTECTED])
wrote:
> > > > > 10% gain in speed is NOT worth major complexity increase.
> > > >
> > > > Should I create a patch to remove rb-tree implementation?
> > >
> > > If you can replace them with something simpler, and no worse
On Thu, Mar 01, 2007 at 12:14:44PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Thursday 01 March 2007 11:59, Evgeniy Polyakov wrote:
>
> > Yes, it is about 98-100% in both cases.
> > I've just re-run tests on my amd64 test machine without debug options:
> >
> > epoll 4794.23
On Thursday 01 March 2007 12:20, Evgeniy Polyakov wrote:
> On Thu, Mar 01, 2007 at 12:14:44PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > On Thursday 01 March 2007 11:59, Evgeniy Polyakov wrote:
> > > Yes, it is about 98-100% in both cases.
> > > I've just re-run tests on my amd64 test mach
On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
> > if then there should be a mechanism /in the hardware/ to set the
> > priority of a CPU - and then the hardware could decide how to prioritize
> > between siblings. Doing this in software is really hard.
>
> And that's the depressing part be
--- Pekka Enberg <[EMAIL PROTECTED]> wrote:
> Yeah, but the oops looks more like a reference counting problem with
> sysfs dentries. No harm in trying out the patch or reproducing without
> CONFIG_SCHED_SMT though.
>
Nope, no difference. Again, this happened while trying to start World of
Warcra
Hi Chris,
On Thu, 1 Mar 2007, Chris Rankin wrote:
> Nope, no difference. Again, this happened while trying to start World of
> Warcraft. However, this time there is no snd-rtctimer module in the
> stack.
Please apply this patch to your kernel and try to reproduce:
http://www.kernel.org/pub/lin
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> I've uploaded them to:
>
> http://tservice.net.ru/~s0mbre/archive/kevent/evserver_epoll.c
> http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent.c
thanks.
> I also changed client socket to nonblocking mode with the same result
> in epol
Andrew Morton wrote:
On Thu, 01 Mar 2007 02:34:02 -0800 Zachary Amsden <[EMAIL PROTECTED]> wrote:
I think on_each_cpu has a serious bug now that hrtimers has been
integrated. Basically, there are many callsites of clock_was_set, none
of which actually know the current interrupt state - ena
On Thu, Mar 01, 2007 at 12:27:00PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > I've uploaded them to:
> >
> > http://tservice.net.ru/~s0mbre/archive/kevent/evserver_epoll.c
> > http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent
On Thu, 2007-03-01 at 03:34 -0800, Zachary Amsden wrote:
> What would be really, really nice would be to statically check all
> callsites that issue irq disables actually keep irqs disabled.
> Presumably, there was a reason they disabled irqs, and re-enabling them
> underneath their noses, even
Rusty Russell wrote:
On Thu, 2007-03-01 at 03:34 -0800, Zachary Amsden wrote:
What would be really, really nice would be to statically check all
callsites that issue irq disables actually keep irqs disabled.
Presumably, there was a reason they disabled irqs, and re-enabling them
underneath
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> I also changed client socket to nonblocking mode with the same result
> in epoll server. If you will find it broken, please send me corrected
> to test too.
this line in evserver_kevent.c looks a bit fishy:
err = recv(s, buf, 100, 0);
b
On Thu, Mar 01, 2007 at 12:28:00PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Thursday 01 March 2007 12:20, Evgeniy Polyakov wrote:
> > On Thu, Mar 01, 2007 at 12:14:44PM +0100, Eric Dumazet ([EMAIL PROTECTED])
> wrote:
> > > On Thursday 01 March 2007 11:59, Evgeniy Polyakov wrote:
> > >
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > I also changed client socket to nonblocking mode with the same result
> > in epoll server. If you will find it broken, please send me corrected
> > to test too.
>
> this line in evserver_kevent.c looks a bit fishy:
this one in evserver_kevent.c loo
On Thu, Mar 01, 2007 at 02:53:21AM -0800, Jeremy Fitzhardinge wrote:
> Adrian Bunk wrote:
>...
> > struct shared_info *HYPERVISOR_shared_info = &init_shared;
> > -EXPORT_SYMBOL(HYPERVISOR_shared_info);
>
> Are you sure? I thought I added this because akpm was getting compile
> errors with allmo
On Thu, Mar 01, 2007 at 12:41:37PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > I also changed client socket to nonblocking mode with the same result
> > in epoll server. If you will find it broken, please send me corrected
> > to test to
On Thursday 01 March 2007 22:33, Thomas Gleixner wrote:
> On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
> > > if then there should be a mechanism /in the hardware/ to set the
> > > priority of a CPU - and then the hardware could decide how to
> > > prioritize between siblings. Doing this in
I think what you're describing here is just the standard old
smp_call_function() deadlock, rather than anything which is specific to
intel-rng, yes?
It is "well known" that you can't call smp_call_function() with local
interrupts disabled. In fact i386 will spit a warning if you try it.
inte
On Thu, Mar 01, 2007 at 12:47:35PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > > I also changed client socket to nonblocking mode with the same result
> > > in epoll server. If you will find it broken, please send me corrected
> > > to test t
On Thu, 2007-03-01 at 23:05 +1100, Con Kolivas wrote:
> > > And that's the depressing part because of course I was interested in that
> > > as the original approach to the problem (and it was a big problem). When
> > > I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at
> > > ker
Am Mittwoch, 28. Februar 2007 19:02 schrieb Dan Williams:
> I can reliably reproduce a null pointer dereference on 2.6.20 and
> 2.6.21-rc2. I will keep digging to find the kernel version where
> this last worked, but wanted to see if there were any immediate
> experiments I should try.
> ...
> Ker
1 - 100 of 535 matches
Mail list logo
