headers
Alan | 1 Dec 2006 01:00
Picon

Re: What happened to CONFIG_TCP_NAGLE_OFF?

> No, nagle was invented specifically for telnet.  Without nagle, every 

No it was general purpose. It fixes some extremely bad behaviour in TCP
with congestion well beyond the "telnet" behaviour.

> Things like mouse movements should not be sent over TCP at all.  UDP 
> makes a much better protocol for that kind of data since if a packet is 

UDP is rarely appropriate because it has no congestion control. There are
more appropriate protocols but they are rarely implemented so TCP
generally gets used.

> lost, there is no need to retransmit the same data; instead you just get 
> the next position update and don't care about where the mouse was during 
> the dropped packet.
Permalink | Reply | 3 comments |
headers
Peter Williams | 1 Dec 2006 01:01
Picon
Gravatar

[ANNOUNCE][RFC] PlugSched-6.4 for 2.6.19

This version removes the hard/soft CPU rate caps from the SPA schedulers.

A patch for 2.6.19 is available at:

<http://prdownloads.sourceforge.net/cpuse/plugsched-6.4-for-2.6.19.patch?download>

Very Brief Documentation:

You can select a default scheduler at kernel build time.  If you wish to
boot with a scheduler other than the default it can be selected at boot
time by adding:

cpusched=<scheduler>

to the boot command line where <scheduler> is one of: ingosched,
ingo_ll, nicksched, staircase, spa_no_frills, spa_ws, spa_svr, spa_ebs
or zaphod.  If you don't change the default when you build the kernel
the default scheduler will be ingosched (which is the normal scheduler).

The scheduler in force on a running system can be determined by the
contents of:

/proc/scheduler

Control parameters for the scheduler can be read/set via files in:

/sys/cpusched/≤scheduler>/

Peter
--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Hancock | 1 Dec 2006 01:07
Picon
Favicon

Re: [RFC PATCH] nForce4 ADMA with NCQ: It's aliiiive..

Prakash Punnoor wrote:
> Am Dienstag 10 Oktober 2006 08:44 schrieb Allen Martin:
> 
>> No, only CK804 and MCP04 support ADMA.  We'll be publishing some patches
>> for NCQ support for MCP55/MCP61 soon.
> 
> Just wondering whether I missed them? It is now 1,5 month later...

I don't think you missed them.. It would be nice to get this support in, 
those are the last NVIDIA chipsets which have NCQ support (apparently) 
that don't support it under Linux. Even just the hardware docs would be 
useful..

---
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr <at> nospamshaw.ca
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Paul Jackson | 1 Dec 2006 01:10
Picon
Favicon

Re: bitmap­_find_free_region and bitmap_full arg doubts


  M. R. Brown and Paul Mundt -- take a look at the question at end of this post.

Komal wrote:
> 
> I have attached the test module code. I have confusion about the what
> to pass as second argument of bitmap_find_free_region for 2nd layer
> bitmap.
> 
> Do we have to pass "total size of the block...here 128MB" as the
> second argument or no. of bits in that block, which 32768 (128 >>
> PAGE_SHIFT) ?
> 
> This confusion arised as store queue implementation (sq.c) of sh arch,
> passes total size of the bitmap (64M) as the second argument instead
> of bits.
> 
> Same is the case with bitmap_full, where I have to pass total size of
> the block (here 128MB) instead of no. of bits, in-order it to make my
> test module work correctly.

A bitmap is essentially an array of bits.  The bitmap_* routines should
take a count of how many bits are in the bitmap array (or in your case,
how many bits are in the segment that you expect to be used in that call.)

So I'm guessing you will be passing L2_BM_BITS for that second argument.

The call to bitmap_find_free_region(), in arch/sh/kernel/cpu/sh4/sq.c
looks bogus:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Oleg Nesterov | 1 Dec 2006 01:14
Picon

Re: [RFC, PATCH 1/2] qrcu: "quick" srcu implementation

Hopefully the final version: added a comment (thanks Paul!) for the
2-nd smp_mb().

[RFC, PATCH 1/2] qrcu: "quick" srcu implementation

Very much based on ideas, corrections, and patient explanations from
Alan and Paul.

The current srcu implementation is very good for readers, lock/unlock
are extremely cheap. But for that reason it is not possible to avoid
synchronize_sched() and polling in synchronize_srcu().

Jens Axboe wrote:
>
> It works for me, but the overhead is still large. Before it would take
> 8-12 jiffies for a synchronize_srcu() to complete without there actually
> being any reader locks active, now it takes 2-3 jiffies. So it's
> definitely faster, and as suspected the loss of two of three
> synchronize_sched() cut down the overhead to a third.

'qrcu' behaves the same as srcu but optimized for writers. The fast path
for synchronize_qrcu() is mutex_lock() + atomic_read() + mutex_unlock().
The slow path is __wait_event(), no polling. However, the reader does
atomic inc/dec on lock/unlock, and the counters are not per-cpu.

Also, unlike srcu, qrcu read lock/unlock can be used in interrupt context,
and 'qrcu_struct' can be compile-time initialized.

See also (a long) discussion:
	http://marc.theaimsgroup.com/?t=116370857600003
(Continue reading)

Permalink | Reply | 1 comment |
headers
Olivier Galibert | 1 Dec 2006 01:19
Picon
Favicon

Re: [PATCH] PCI MMConfig: Detect and support the E7520 and the 945G/GZ/P/PL

On Mon, Nov 27, 2006 at 09:24:06PM +0100, Olivier Galibert wrote:
> On Mon, Nov 27, 2006 at 08:07:48PM +0100, Andi Kleen wrote:
> > Is that with just the code movement patch or your feature patch
> > added too? If the later can you test it with only code movement
> > (and compare against vanilla kernel). at least code movement
> > only should behave exactly the same as unpatched kernel.
> 
> You misread.  Unpatched kernel does not work.  That's why I gave the
> git reference of the kernel too.  Patched kernel does not work either,
> unsurprisingly (bios gives correct tables on that box).

Ok, I'm trying to debug it, and it's a pain.  It's a timing issue,
mmcfg write accesses are too slow for something.  The get_base_addr()
call is enough to slow things down too much, which explains why the
fundamentally simpler x86-64 code works without a hitch.

Finding out what it is too slow for, though, is an interesting
proposition.  It's not entirely obvious it is actually related to the
sata accesses.

  OG.
Permalink | Reply | 0 comments |
headers
Nick Piggin | 1 Dec 2006 01:27
Picon

Re: [patch 3/3] fs: fix cont vs deadlock patches

On Fri, Dec 01, 2006 at 07:14:28AM +0900, OGAWA Hirofumi wrote:
> 
> quick look. Doesn't this break reiserfs? IIRC, the reiserfs is using
> it for another reason. I was also working for this, but I lost the
> thread of this, sorry.

Yes I think it will break reiserfs, so I just have to have a look
at converting it. Shouldn't take too long.

> 
> I found some another users (affs, hfs, hfsplus). Those seem have same
> problem, but probably those also can use this...
> 
> What do you think?

Well I guess this is your code, so it is up to you ;)

I would be happy if you come up with a quick fix, I'm just trying to
stamp out a few big bugs in mm. However I did prefer my way of moving
all the exapand code into generic_cont_expand, out of prepare_write, and
avoiding holding the target page locked while we're doing all the expand
work (strictly, you might be able to get away with this, but it is
fragile and ugly).

AFAIKS, the only reason to use prepare_write is to avoid passing the
get_block into generic_cont_expand?

Thanks,
Nick
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Mundt | 1 Dec 2006 01:42
Gravatar

Re: bitmap?_find_free_region and bitmap_full arg doubts

On Thu, Nov 30, 2006 at 04:10:08PM -0800, Paul Jackson wrote:
> The call to bitmap_find_free_region(), in arch/sh/kernel/cpu/sh4/sq.c
> looks bogus:
> 
>         page = bitmap_find_free_region(sq_bitmap, 0x04000000,
>                                        get_order(map->size));
> 
> It says the bitmap has 0x04000000 bits.  This would take 0x04000000 / 8
> which is 8388608 (decimal) bytes to hold.  That's an insanely
> huge bitmap - 8 million bytes worth of bits.
> 
Ouch, you're right, for some reason we missed the >> PAGE_SHIFT here,
even though it was handled properly in sq_api_init(). I suppose we
haven't hit this in practice as most of the users end up being quite
small. I'll fix it up. Good catch, thanks!
Permalink | Reply | 1 comment |
headers
Tejun Heo | 1 Dec 2006 01:50
Picon

Re: ICH6M SATA Controller, SATA2 NCQ disk and high iowait CPU time

gary.czek wrote:
> "vmstat 5" when system is really slow shows following:
> 
> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
>  0  9 285904   3044    832  42088   75   46   247    98  484  746  5  2 80 13
>  0  4 285560   3628    692  43724  686   71   913   418  952 1651 18  3  0 79
>  0  3 285000   3616    688  43100  822   15  1431   766  939 1761 16  4  0 80
>  0  3 284372   3612    700  42344  703    0  1234    43  941 1697 18  3  7 72
>  1  2 284012   3176    580  42800  406    0  1054    74  834 1602 15  4 36 45
>  0  3 283820   3888    824  40044  413   23  1102    95  865 1767 17  3  0 80
>  0  1 286364   3904    900  41508   63  540  1023   629  928 1646 15  3  0 82
>  0  2 287500   4884   1120  44840  388  338  1606   431  902 1670 13  4  0 83
>  0 10 291148   3104   1296  46088  396  827   923   877  917 1521 10  3  0 87
>  0  3 292952   3728   1492  47524  259  474   730   606  889 1754 15  2  0 84
>  0  2 294960   3540   1588  47488  633  632   970   678  863 1630 12  2  0 86
>  0  2 297444   3828   1676  46496  648  674   774   735  886 1906 14  2  0 84
>  0  3 298184   3616   1684  46420  593  290   759   331  844 1792 12  3  0 85
>  0  5 297836   3852   1508  43576  632  168   990   229  814 1605 10  1  0 88

Your machine is thrashing.  Working set size is over the available
memory and pages are continuously getting dropped and then brought back.
 Run top and press 'M' after the list showed up.  It will show who are
consuming all the memory.  Adding 1G should solve the problem but just
another 256M will make a big difference too.

--

-- 
tejun
Permalink | Reply | 1 comment |
headers
Paul Jackson | 1 Dec 2006 02:01
Picon
Favicon

Re: bitmap?_find_free_region and bitmap_full arg doubts

Paul Mundt wrote:
> I'll fix it up. Good catch, thanks!

You're welcome.

--

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj <at> sgi.com> 1.925.600.0401
Permalink | Reply | 0 comments |

Gmane