twitter: linux.kernel - 26 new messages in 16 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Nested SVM fixes (and Win7-64bit bringup) - 5 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/b608877f8fa7c926?hl=en
* add_timer_on: in-kernel users _all_ buggy ? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/10ba4cd052c77aef?hl=en
* tracing/kprobes: Make Kconfig dependencies generic - 5 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/f25a85a28b5e0740?hl=en
* net: TCP thin dupack - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/45be4449975ad2af?hl=en
* SSD on Linux - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1947b46d47764a62?hl=en
* kdb: core for kgdb back end (2 of 2) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7d1f7060382d45a9?hl=en
* cciss: remove C99-style comments - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1d7e205de67bef95?hl=en
* cciss: Consolidate duplicate bits in cciss_cmd.h & cciss_ioctl.h - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/e80efb969c58f15f?hl=en
* gpio: introduce it8761e_gpio driver for IT8761E Super I/O chip - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/8d7b6fa691a13d87?hl=en
* Documentation: remove obsolete voyager.txt file - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2568fc504a3bffe5?hl=en
* linux-next: manual merge of the als tree with Linus' tree - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/d4da49591502cde8?hl=en
* x86-32: use SSE for atomic64_read/set if available - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c7fe1bc8eb70e0f9?hl=en
* Export unusable free space index via /proc/pagetypeinfo - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/8f3afebfb2eb60df?hl=en
* Uncool feature for TTM introduced by x86, pat: Use page flags to track
memtypes of RAM pages - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e6028262be4092ae?hl=en
* Export fragmentation index via /proc/pagetypeinfo - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c8c288ab151c09bb?hl=en
* Loan Offer - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8de9d77f99f99e86?hl=en

==============================================================================
TOPIC: Nested SVM fixes (and Win7-64bit bringup)
http://groups.google.com/group/linux.kernel/t/b608877f8fa7c926?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Feb 18 2010 6:40 am
From: Avi Kivity

On 02/18/2010 01:38 PM, Joerg Roedel wrote:
> Hi,
>
> here is a couple of fixes for the nested SVM implementation. I collected these
> fixes mostly when trying to get Windows 7 64bit running as an L2 guest. Most
> important fixes in this set make lazy fpu switching working with nested SVM and
> the nested tpr handling fixes. Without the later fix the l1 guest freezes when
> trying to run win7 as l2 guest. Please review and comment on these patches :-)
>

Overall looks good. Would appreciate Alex looking over these as well.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 5 ==
Date: Thurs, Feb 18 2010 6:50 am
From: Alexander Graf

On 18.02.2010, at 15:33, Avi Kivity wrote:

> On 02/18/2010 01:38 PM, Joerg Roedel wrote:
>> Hi,
>>
>> here is a couple of fixes for the nested SVM implementation. I collected these
>> fixes mostly when trying to get Windows 7 64bit running as an L2 guest. Most
>> important fixes in this set make lazy fpu switching working with nested SVM and
>> the nested tpr handling fixes. Without the later fix the l1 guest freezes when
>> trying to run win7 as l2 guest. Please review and comment on these patches :-)
>>
>
> Overall looks good. Would appreciate Alex looking over these as well.

The kmap thing is broken though, right?

Alex--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 5 ==
Date: Thurs, Feb 18 2010 7:00 am
From: Avi Kivity

On 02/18/2010 04:51 PM, Alexander Graf wrote:
> On 18.02.2010, at 12:38, Joerg Roedel wrote:
>
>
>> TDB.
>>
> TDB? That's not a patch description.
>
>

Short for "To De Befined", I presume.

--
error compiling committee.c: too many arguments to function

== 4 of 5 ==
Date: Thurs, Feb 18 2010 7:00 am
From: Alexander Graf

On 18.02.2010, at 12:38, Joerg Roedel wrote:

> TDB.

TDB? That's not a patch description.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 5 of 5 ==
Date: Thurs, Feb 18 2010 7:00 am
From: Avi Kivity

On 02/18/2010 04:48 PM, Alexander Graf wrote:
> On 18.02.2010, at 15:33, Avi Kivity wrote:
>
>
>> On 02/18/2010 01:38 PM, Joerg Roedel wrote:
>>
>>> Hi,
>>>
>>> here is a couple of fixes for the nested SVM implementation. I collected these
>>> fixes mostly when trying to get Windows 7 64bit running as an L2 guest. Most
>>> important fixes in this set make lazy fpu switching working with nested SVM and
>>> the nested tpr handling fixes. Without the later fix the l1 guest freezes when
>>> trying to run win7 as l2 guest. Please review and comment on these patches :-)
>>>
>>>
>> Overall looks good. Would appreciate Alex looking over these as well.
>>
> The kmap thing is broken though, right?
>

Oh yes, but that's a search and replace, not something needing deep rework.

--
error compiling committee.c: too many arguments to function

==============================================================================
TOPIC: add_timer_on: in-kernel users _all_ buggy ?
http://groups.google.com/group/linux.kernel/t/10ba4cd052c77aef?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 6:40 am
From: Mathieu Desnoyers

* Mathieu Desnoyers (compudj@krystal.dyndns.org) wrote:
> * Thomas Gleixner (tglx@linutronix.de) wrote:
> > On Tue, 16 Feb 2010, Mathieu Desnoyers wrote:
> > > > The function is called from an IPI. That's a LTTNG problem, not a RT one.
> > >
> > > I use del_timer in IPI to delete lttng per-cpu timers on all CPUs. I
> > > have to do this because timers created with add_timer_on are documented
> > > to be incompatible with del_timer_sync():
> > >
> > > * Synchronization rules: Callers must prevent restarting of the timer,
> > > * otherwise this function is meaningless. It must not be called from
> > > * interrupt contexts. The caller must not hold locks which would prevent
> > > * completion of the timer's handler. The timer's handler must not call
> > > * add_timer_on(). Upon exit the timer is not queued and the handler is
> > > * not running on any CPU.
> >
> > Errm. The documentation says:
> >
> > "The timer's handler must not call add_timer_on()."
> >
> > It's not talking about a timer which was initialized with
> > add_timer_on().
> >
> > And your per cpu timer handlers have no requirement to call
> > add_timer_on() simply because add/mod_timer() is requeueing the timer
> > on the same cpu on which the handler runs.
> >
> > So the IPI is just a solution for a non existing problem.
>
> Oh, right. Thanks for the explanation. I'll look into moving LTTng to a
> saner del_timer_sync() scheme to delete the timers.

Double-checking this:

add_timer_on() needs to be paired with mod_timer_pinned(), otherwise
NO_HZ SMP config can rebalance the timer to a different CPU. I am fixing
this in lttng 0.194. These per-cpu timers, of course, should usually be
deferrable (they are in lttng).

(looking at kernel 2.6.32.4 here)
Looking at the kernel/time/clocksource.c watchdog, I wonder how
del_timer manages to synchronize the timer teardown. The handler,
clocksource_watchdog(), uses add_timer_on(), which prohibits using
del_timer_sync(). This seems rather odd. If we remove the watchdog and
re-add it, it may still be in use while we initialize the timer
structure.

Also, net/core/drop_monitor.c trace_drop_common usage of add_timer_on
seems odd:

Executing (AFAIK) with preempt on, data points to a per-cpu timer:

if (!timer_pending(&data->send_timer)) {
data->send_timer.expires = jiffies + dm_delay * HZ;
add_timer_on(&data->send_timer, smp_processor_id());
}

How is timer_pending synchronized with the target CPU timer wheel ?

Wait, there's more: arch/x86/kernel/cpu/mcheck/mce.c uses both
add_timer_on in its handler and del_timer_sync (which is incorrect).

arch/x86/kernel/apic/x2apic_uv_x.c almost has it right, but maybe it
should use del_timer_sync ?

arch/powerpc/platforms/chrp/setup.c should learn about
mod_timer_pinned().

Which leads to the following question: is there _any_ add_timer_on()
kernel user that's not currently buggy ? ;-) Maybe this calls for better
documentation of this interface. From what I've learn from digging into
cpufreq to debug its incorrect timer teardown last year, I fear there
are lots and lots of buggy per-cpu _and_ standard timer interface users
out there.

Maybe adding some debugging options, e.g. checking that a timer created
with add_timer_on is always modified by mod_timer_pinned, and is always
deferrable, and deleted by del_timer_sync could help discovering a
couple of outlawyer.

Thanks,

Mathieu

>
> Thanks,
>
> Mathieu
>
> >
> > Thanks,
> >
> > tglx
> >
>
> --
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev@lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>

--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: tracing/kprobes: Make Kconfig dependencies generic
http://groups.google.com/group/linux.kernel/t/f25a85a28b5e0740?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Feb 18 2010 6:40 am
From: Frederic Weisbecker

On Thu, Feb 18, 2010 at 02:25:21PM +0100, Heiko Carstens wrote:
> Subject: [PATCH] tracing/kprobes: add short documentation for HAVE_REGS_AND_STACK_ACCESS_API
>
> From: Heiko Carstens <heiko.carstens@de.ibm.com>
>
> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>

Thanks, I'm adding it in the set.

> ---
> arch/Kconfig | 4 ++++
> 1 file changed, 4 insertions(+)
>
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -123,6 +123,10 @@ config USE_GENERIC_SMP_HELPERS
>
> config HAVE_REGS_AND_STACK_ACCESS_API
> bool
> + help
> + This symbol should be selected by an architecure if it supports
> + the API needed to access registers and stack entries from pt_regs.
> + For example the kprobes-based event tracer needs this API.
>
> config HAVE_CLK
> bool

== 2 of 5 ==
Date: Thurs, Feb 18 2010 7:00 am
From: Frederic Weisbecker

On Thu, Feb 18, 2010 at 09:01:12AM -0500, Mike Frysinger wrote:
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -123,6 +123,10 @@ config USE_GENERIC_SMP_HELPERS
> >
> > config HAVE_REGS_AND_STACK_ACCESS_API
> > bool
> > + help
> > + This symbol should be selected by an architecure if it supports
> > + the API needed to access registers and stack entries from pt_regs.
> > + For example the kprobes-based event tracer needs this API.
>
> a bit vague ... arent there headers/functions people could look at ?
> perhaps you're talking about the regset functions (which is an API to
> access registers in pt_regs) ? or you're talking about asm/syscall.h
> (which is an API to access registers in pt_regs) ?
>
> i'm not asking to be a pain, i'm asking because i really havent a
> clue. if i wanted to add support for this stuff to the Blackfin arch,
> i wouldnt know where to start. even after reading this help i'd fall
> back to grepping arch/x86/ and trying to divine a starting point from
> there.

If an arch support kprobes, it just needs to select
HAVE_REGS_AND_STACK_ACCESS_API to figure out quickly what is missing,
as gcc will barf every missing clues you need.

For now it is stored is asm/ptrace.h, but that might be split in
the future, especially as ptrace has initially nothing related to
that. A documentation that deals with filenames or API enumerations
tend to be incidentally async with API evolutions.

Hm?

== 3 of 5 ==
Date: Thurs, Feb 18 2010 7:10 am
From: Mike Frysinger

On Thu, Feb 18, 2010 at 10:00, Heiko Carstens wrote:
> On Thu, Feb 18, 2010 at 09:01:12AM -0500, Mike Frysinger wrote:
>> On Thu, Feb 18, 2010 at 08:25, Heiko Carstens wrote:
>> > --- a/arch/Kconfig
>> > +++ b/arch/Kconfig
>> > @@ -123,6 +123,10 @@ config USE_GENERIC_SMP_HELPERS
>> >
>> > config HAVE_REGS_AND_STACK_ACCESS_API
>> > bool
>> > + help
>> > + This symbol should be selected by an architecure if it supports
>> > + the API needed to access registers and stack entries from pt_regs.
>> > + For example the kprobes-based event tracer needs this API.
>>
>> a bit vague ... arent there headers/functions people could look at ?
>> perhaps you're talking about the regset functions (which is an API to
>> access registers in pt_regs) ? or you're talking about asm/syscall.h
>> (which is an API to access registers in pt_regs) ?
>>
>> i'm not asking to be a pain, i'm asking because i really havent a
>> clue. if i wanted to add support for this stuff to the Blackfin arch,
>> i wouldnt know where to start. even after reading this help i'd fall
>> back to grepping arch/x86/ and trying to divine a starting point from
>> there.
>
> git show b1cf540f would be your friend. That's why I pointed out the
> id in the changelog.
> I have no idea what your workflow is, but doing something like
> gitk v2.6.32..v2.6.33-rc1 arch/<whatever>/
> is what I do to figure out what other archs did during the merge
> window and if there's something that needs an arch backend on s390.
> This reveals also bug fixes that need to be ported from time to time.
> That worked pretty well for me during the last few years.

most of the time though such implementations are tied to the arch, and
for people unfamiliar with the arch in question, they can have a hard
time separating the common requirements from the arch requirements.
changelog entries also really shouldnt be the norm for documentation
of APIs, especially as APIs change over time (by design -- linux has
no stable API). so while this commit may be useful for the next
release or two, it isnt uncommon for them to be partially if not
wholly irrelevant down the line. which is when us smaller arches get
around to implementing this cooler features.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 4 of 5 ==
Date: Thurs, Feb 18 2010 7:10 am
From: Mike Frysinger

On Thu, Feb 18, 2010 at 09:50, Frederic Weisbecker wrote:
> On Thu, Feb 18, 2010 at 09:01:12AM -0500, Mike Frysinger wrote:
>> > --- a/arch/Kconfig
>> > +++ b/arch/Kconfig
>> > @@ -123,6 +123,10 @@ config USE_GENERIC_SMP_HELPERS
>> >
>> > config HAVE_REGS_AND_STACK_ACCESS_API
>> > bool
>> > + help
>> > + This symbol should be selected by an architecure if it supports
>> > + the API needed to access registers and stack entries from pt_regs.
>> > + For example the kprobes-based event tracer needs this API.
>>
>> a bit vague ... arent there headers/functions people could look at ?
>> perhaps you're talking about the regset functions (which is an API to
>> access registers in pt_regs) ? or you're talking about asm/syscall.h
>> (which is an API to access registers in pt_regs) ?
>>
>> i'm not asking to be a pain, i'm asking because i really havent a
>> clue. if i wanted to add support for this stuff to the Blackfin arch,
>> i wouldnt know where to start. even after reading this help i'd fall
>> back to grepping arch/x86/ and trying to divine a starting point from
>> there.
>
> If an arch support kprobes, it just needs to select
> HAVE_REGS_AND_STACK_ACCESS_API to figure out quickly what is missing,
> as gcc will barf every missing clues you need.

so should this new Kconfig option have an appropriate depends on
KPROBES or something ?

> For now it is stored is asm/ptrace.h, but that might be split in
> the future, especially as ptrace has initially nothing related to
> that. A documentation that deals with filenames or API enumerations
> tend to be incidentally async with API evolutions.

i dont expect there to be per-function documentation here ... such
things below in the header files themselves (linux/regset.h is an
example of how to approach this). but having a tip of reading a file
or two (like HAVE_ARCH_TRACEHOOK) doesnt bit rot nearly as often. if
the common API expected of headers hasnt yet been split, then i guess
not much left to be done here.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 5 of 5 ==
Date: Thurs, Feb 18 2010 7:10 am
From: Heiko Carstens

On Thu, Feb 18, 2010 at 09:01:12AM -0500, Mike Frysinger wrote:
> On Thu, Feb 18, 2010 at 08:25, Heiko Carstens wrote:
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -123,6 +123,10 @@ config USE_GENERIC_SMP_HELPERS
> >
> > config HAVE_REGS_AND_STACK_ACCESS_API
> > bool
> > + help
> > + This symbol should be selected by an architecure if it supports
> > + the API needed to access registers and stack entries from pt_regs.
> > + For example the kprobes-based event tracer needs this API.
>
> a bit vague ... arent there headers/functions people could look at ?
> perhaps you're talking about the regset functions (which is an API to
> access registers in pt_regs) ? or you're talking about asm/syscall.h
> (which is an API to access registers in pt_regs) ?
>
> i'm not asking to be a pain, i'm asking because i really havent a
> clue. if i wanted to add support for this stuff to the Blackfin arch,
> i wouldnt know where to start. even after reading this help i'd fall
> back to grepping arch/x86/ and trying to divine a starting point from
> there.

git show b1cf540f would be your friend. That's why I pointed out the
id in the changelog.
I have no idea what your workflow is, but doing something like
gitk v2.6.32..v2.6.33-rc1 arch/<whatever>/
is what I do to figure out what other archs did during the merge
window and if there's something that needs an arch backend on s390.
This reveals also bug fixes that need to be ported from time to time.
That worked pretty well for me during the last few years.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: net: TCP thin dupack
http://groups.google.com/group/linux.kernel/t/45be4449975ad2af?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 6:50 am
From: Andreas Petlund

This patch enables fast retransmissions after one dupACK for
TCP if the stream is identified as thin. This will reduce
latencies for thin streams that are not able to trigger fast
retransmissions due to high packet interarrival time. This
mechanism is only active if enabled by iocontrol or syscontrol
and the stream is identified as thin.

Signed-off-by: Andreas Petlund <apetlund@simula.no>
---
Documentation/networking/ip-sysctl.txt | 12 ++++++++++++
include/linux/tcp.h | 4 +++-
include/net/tcp.h | 1 +
net/ipv4/sysctl_net_ipv4.c | 7 +++++++
net/ipv4/tcp.c | 7 +++++++
net/ipv4/tcp_input.c | 12 ++++++++++++
6 files changed, 42 insertions(+), 1 deletions(-)

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index f147310..2571a62 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -499,6 +499,18 @@ tcp_thin_linear_timeouts - BOOLEAN
Documentation/networking/tcp-thin.txt
Default: 0

+tcp_thin_dupack - BOOLEAN
+ Enable dynamic triggering of retransmissions after one dupACK
+ for thin streams. If set, a check is performed upon reception
+ of a dupACK to determine if the stream is thin (less than 4
+ packets in flight). As long as the stream is found to be thin,
+ data is retransmitted on the first received dupACK. This
+ improves retransmission latency for non-aggressive thin
+ streams, often found to be time-dependent.
+ For more information on thin streams, see
+ Documentation/networking/tcp-thin.txt
+ Default: 0
+
UDP variables:

udp_mem - vector of 3 INTEGERs: min, pressure, max
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 3ba8b07..a778ee0 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -104,6 +104,7 @@ enum {
#define TCP_MD5SIG 14 /* TCP MD5 Signature (RFC2385) */
#define TCP_COOKIE_TRANSACTIONS 15 /* TCP Cookie Transactions */
#define TCP_THIN_LINEAR_TIMEOUTS 16 /* Use linear timeouts for thin streams*/
+#define TCP_THIN_DUPACK 17 /* Fast retrans. after 1 dupack */

/* for TCP_INFO socket option */
#define TCPI_OPT_TIMESTAMPS 1
@@ -343,7 +344,8 @@ struct tcp_sock {
u8 frto_counter; /* Number of new acks after RTO */
u8 nonagle : 4,/* Disable Nagle algorithm? */
thin_lto : 1,/* Use linear timeouts for thin streams */
- unused : 3;
+ thin_dupack : 1,/* Fast retransmit on first dupack */
+ unused : 2;

/* RTT measurement */
u32 srtt; /* smoothed round trip time << 3 */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 6278fc7..56f0aec 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -245,6 +245,7 @@ extern int sysctl_tcp_slow_start_after_idle;
extern int sysctl_tcp_max_ssthresh;
extern int sysctl_tcp_cookie_size;
extern int sysctl_tcp_thin_linear_timeouts;
+extern int sysctl_tcp_thin_dupack;

extern atomic_t tcp_memory_allocated;
extern struct percpu_counter tcp_sockets_allocated;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index e6a2460..c1bc074 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -582,6 +582,13 @@ static struct ctl_table ipv4_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "tcp_thin_dupack",
+ .data = &sysctl_tcp_thin_dupack,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
{
.procname = "udp_mem",
.data = &sysctl_udp_mem,
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 21bae9a..5901010 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2236,6 +2236,13 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
tp->thin_lto = val;
break;

+ case TCP_THIN_DUPACK:
+ if (val < 0 || val > 1)
+ err = -EINVAL;
+ else
+ tp->thin_dupack = val;
+ break;
+
case TCP_CORK:
/* When set indicates to always queue non-full frames.
* Later the user clears this option and we transmit
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 3fddc69..788851c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -89,6 +89,8 @@ int sysctl_tcp_frto __read_mostly = 2;
int sysctl_tcp_frto_response __read_mostly;
int sysctl_tcp_nometrics_save __read_mostly;

+int sysctl_tcp_thin_dupack __read_mostly;
+
int sysctl_tcp_moderate_rcvbuf __read_mostly = 1;
int sysctl_tcp_abc __read_mostly;

@@ -2447,6 +2449,16 @@ static int tcp_time_to_recover(struct sock *sk)
return 1;
}

+ /* If a thin stream is detected, retransmit after first
+ * received dupack. Employ only if SACK is supported in order
+ * to avoid possible corner-case series of spurious retransmissions
+ * Use only if there are no unsent data.
+ */
+ if ((tp->thin_dupack || sysctl_tcp_thin_dupack) &&
+ tcp_stream_is_thin(tp) && tcp_dupack_heuristics(tp) > 1 &&
+ tcp_is_sack(tp) && !tcp_send_head(sk))
+ return 1;
+
return 0;
}

--
1.6.3.3

==============================================================================
TOPIC: SSD on Linux
http://groups.google.com/group/linux.kernel/t/1947b46d47764a62?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:00 am
From: "Fred ."

I just purchased an Intel X25-M G2 80 gb SSD.
I know Linus had an Intel SSD drive, and liked it.

I was wondering if I should make any changes to the system when using
an SSD drive?

How should I optimize my system for SSD?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: kdb: core for kgdb back end (2 of 2)
http://groups.google.com/group/linux.kernel/t/7d1f7060382d45a9?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:10 am
From: Jason Wessel

Eric W. Biederman wrote:
> Jason Wessel <jason.wessel@windriver.com> writes:
>
>
>> This patch contains the hooks and instrumentation into kernel which
>> live outside the kernel/debug directory, which the kdb core
>> will call to run commands like lsmod, dmesg, bt etc...
>>
>
> You know this dropping the locks from vmalloc_info and swap_info
> is down right ugly, and I don't believe it is safe. That code
> was not designed to run while the write_lock is held.
>

Perhaps we can find some middle ground. I don't mind simply not
allowing the information to be queried from kdb if the locks are not
available.

Which is less ugly you, making the swap_lock global or adding a function
to query it?

> How does kdb build if NOMMU is set?
>

I did not see a kernel config option called NOMMU.

Can you point me to a kernel config that uses this? Or is it the case
that it is something like "# CONFIG_MMU is not set"?

Perhaps we just set kdb to work only when CONFIG_MMU is enabled? It is
hard to say it works or not without a kernel configuration, file system
and hardware to test it with.

> Similarly with si_swapinfo. What makes it safe to run the
> code without it's locks. Safe as in no null pointer deferences
> or other nasties.
>
>

It looks to me like the original kdb took the approach of calling the
setjmp() longjmp() and if there was any kind of fault, it long jumped
back to the original context. Obviously that doesn't solve any kind of
problem with a list loop.

As I mentioned earlier, I think we should check for the lock and if it
isn't available you don't get to execute the function, else a separate
function has to be written that does the same thing safely. I do not
see any value in making a separate function to safely print the
information at this time. If you want to probe around, consider using a
gdb macro.

> I am not impressed with the mess you make of meminfo_proc_show.
> That looks like a maintenance hazard if I ever saw one. An innocent
> change to get some additional info (that happens to take a lock)
> will cause kdb to deadlock.
>
>

This code goes away if we expose a way to check for the lock.

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: cciss: remove C99-style comments
http://groups.google.com/group/linux.kernel/t/1d7e205de67bef95?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:10 am
From: scameron@beardog.cce.hp.com

On Wed, Feb 17, 2010 at 04:53:31PM -0700, dann frazier wrote:
> Some cleanup before the header file split-out so we don't propagate this style
> into new files.
>
> Signed-off-by: dann frazier <dannf@hp.com>
[...]
Acked-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: cciss: Consolidate duplicate bits in cciss_cmd.h & cciss_ioctl.h
http://groups.google.com/group/linux.kernel/t/e80efb969c58f15f?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:10 am
From: scameron@beardog.cce.hp.com

On Wed, Feb 17, 2010 at 04:55:11PM -0700, dann frazier wrote:
> There are several duplicate definitions in cciss_cmd.h and cciss_ioctl.h.
> Consolidate these into the new cciss_defs.h file. This patch doesn't change
> the definitions exposed under include/linux, so userspace apps shouldn't
> be affected.
>
> Signed-off-by: dann frazier <dannf@hp.com>

Acked-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>

==============================================================================
TOPIC: gpio: introduce it8761e_gpio driver for IT8761E Super I/O chip
http://groups.google.com/group/linux.kernel/t/8d7b6fa691a13d87?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:20 am
From: Denis Turischev

Signed-off-by: Denis Turischev <denis@compulab.co.il>

diff -Nru linux-2.6.33-rc7.orig/drivers/gpio/it8761e_gpio.c linux-2.6.33-rc7/drivers/gpio/it8761e_gpio.c
--- linux-2.6.33-rc7.orig/drivers/gpio/it8761e_gpio.c 1970-01-01 02:00:00.000000000 +0200
+++ linux-2.6.33-rc7/drivers/gpio/it8761e_gpio.c 2010-02-18 17:04:15.000000000 +0200
@@ -0,0 +1,231 @@
+/*
+ * it8761_gpio.c - GPIO interface for IT8761E Super I/O chip
+ *
+ * Author: Denis Turischev <denis@compulab.co.il>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License 2 as published
+ * by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING. If not, write to
+ * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/errno.h>
+#include <linux/ioport.h>
+
+#include <linux/gpio.h>
+
+#define SIO_CHIP_ID 0x8761
+#define CHIP_ID_HIGH_BYTE 0x20
+#define CHIP_ID_LOW_BYTE 0x21
+
+static u8 ports[2] = { 0x2e, 0x4e };
+static u8 port;
+
+static DEFINE_SPINLOCK(sio_lock);
+
+#define GPIO_NAME "it8761-gpio"
+#define GPIO_BA_HIGH_BYTE 0x60
+#define GPIO_BA_LOW_BYTE 0x61
+#define GPIO_IOSIZE 4
+#define GPIO1X_IO 0xf0
+#define GPIO2X_IO 0xf1
+
+static u16 gpio_ba;
+
+static u8 read_reg(u8 addr, u8 port)
+{
+ outb(addr, port);
+ return inb(port + 1);
+}
+
+static void write_reg(u8 data, u8 addr, u8 port)
+{
+ outb(addr, port);
+ outb(data, port + 1);
+}
+
+static void enter_conf_mode(u8 port)
+{
+ outb(0x87, port);
+ outb(0x61, port);
+ outb(0x55, port);
+ outb((port == 0x2e) ? 0x55 : 0xaa, port);
+}
+
+static void exit_conf_mode(u8 port)
+{
+ outb(0x2, port);
+ outb(0x2, port + 1);
+}
+
+static void enter_gpio_mode(u8 port)
+{
+ write_reg(0x2, 0x7, port);
+}
+
+static int it8761e_gpio_get(struct gpio_chip *gc, unsigned gpio_num)
+{
+ u16 reg;
+ u8 bit;
+
+ bit = gpio_num % 7;
+ reg = (gpio_num >= 7) ? gpio_ba + 1 : gpio_ba;
+
+ return !!(inb(reg) & (1 << bit));
+}
+
+static int it8761e_gpio_direction_in(struct gpio_chip *gc, unsigned gpio_num)
+{
+ u8 curr_dirs;
+ u8 io_reg, bit;
+
+ bit = gpio_num % 7;
+ io_reg = (gpio_num >= 7) ? GPIO2X_IO : GPIO1X_IO;
+
+ spin_lock(&sio_lock);
+
+ enter_conf_mode(port);
+ enter_gpio_mode(port);
+
+ curr_dirs = read_reg(io_reg, port);
+
+ if (curr_dirs & (1 << bit))
+ write_reg(curr_dirs & ~(1 << bit), io_reg, port);
+
+ exit_conf_mode(port);
+
+ spin_unlock(&sio_lock);
+ return 0;
+}
+
+static void it8761e_gpio_set(struct gpio_chip *gc,
+ unsigned gpio_num, int val)
+{
+ u8 curr_vals, bit;
+ u16 reg;
+
+ bit = gpio_num % 7;
+ reg = (gpio_num >= 7) ? gpio_ba + 1 : gpio_ba;
+
+ spin_lock(&sio_lock);
+
+ curr_vals = inb(reg);
+ if (val)
+ outb(curr_vals | (1 << bit) , reg);
+ else
+ outb(curr_vals & ~(1 << bit), reg);
+
+ spin_unlock(&sio_lock);
+}
+
+static int it8761e_gpio_direction_out(struct gpio_chip *gc,
+ unsigned gpio_num, int val)
+{
+ u8 curr_dirs, io_reg, bit;
+
+ bit = gpio_num % 7;
+ io_reg = (gpio_num >= 7) ? GPIO2X_IO : GPIO1X_IO;
+
+ it8761e_gpio_set(gc, gpio_num, val);
+
+ spin_lock(&sio_lock);
+
+ enter_conf_mode(port);
+ enter_gpio_mode(port);
+
+ curr_dirs = read_reg(io_reg, port);
+
+ if (!(curr_dirs & (1 << bit)))
+ write_reg(curr_dirs | (1 << bit), io_reg, port);
+
+ exit_conf_mode(port);
+
+ spin_unlock(&sio_lock);
+ return 0;
+}
+
+static struct gpio_chip it8761e_gpio_chip = {
+ .label = GPIO_NAME,
+ .owner = THIS_MODULE,
+ .get = it8761e_gpio_get,
+ .direction_input = it8761e_gpio_direction_in,
+ .set = it8761e_gpio_set,
+ .direction_output = it8761e_gpio_direction_out,
+};
+
+static int __init it8761e_gpio_init(void)
+{
+ int i, id, err;
+
+ /* chip and port detection */
+ for (i = 0; i < ARRAY_SIZE(ports); i++) {
+ spin_lock(&sio_lock);
+ enter_conf_mode(ports[i]);
+
+ id = (read_reg(CHIP_ID_HIGH_BYTE, ports[i]) << 8) +
+ read_reg(CHIP_ID_LOW_BYTE, ports[i]);
+
+ exit_conf_mode(ports[i]);
+ spin_unlock(&sio_lock);
+
+ if (id == SIO_CHIP_ID) {
+ port = ports[i];
+ break;
+ }
+ }
+
+ if (!port)
+ return -ENODEV;
+
+ /* fetch GPIO base address */
+ enter_conf_mode(port);
+ enter_gpio_mode(port);
+ gpio_ba = (read_reg(GPIO_BA_HIGH_BYTE, port) << 8) +
+ read_reg(GPIO_BA_LOW_BYTE, port);
+ exit_conf_mode(port);
+
+ if (!request_region(gpio_ba, GPIO_IOSIZE, GPIO_NAME))
+ return -EBUSY;
+
+ it8761e_gpio_chip.base = -1;
+ it8761e_gpio_chip.ngpio = 14;
+
+ err = gpiochip_add(&it8761e_gpio_chip);
+ if (err < 0)
+ goto gpiochip_add_err;
+
+ return 0;
+
+gpiochip_add_err:
+ release_region(gpio_ba, GPIO_IOSIZE);
+ gpio_ba = 0;
+ return err;
+}
+
+static void __exit it8761e_gpio_exit(void)
+{
+ if (gpio_ba) {
+ gpiochip_remove(&it8761e_gpio_chip);
+
+ release_region(gpio_ba, GPIO_IOSIZE);
+ gpio_ba = 0;
+ }
+}
+module_init(it8761e_gpio_init);
+module_exit(it8761e_gpio_exit);
+
+MODULE_AUTHOR("Denis Turischev <denis@compulab.co.il>");
+MODULE_DESCRIPTION("GPIO interface for IT8761E Super I/O chip");
+MODULE_LICENSE("GPL");
diff -Nru linux-2.6.33-rc7.orig/drivers/gpio/Kconfig linux-2.6.33-rc7/drivers/gpio/Kconfig
--- linux-2.6.33-rc7.orig/drivers/gpio/Kconfig 2010-02-07 00:17:12.000000000 +0200
+++ linux-2.6.33-rc7/drivers/gpio/Kconfig 2010-02-17 18:52:33.000000000 +0200
@@ -85,6 +85,12 @@
help
Say yes here to support the NEC VR4100 series General-purpose I/O Uint

+config GPIO_IT8761E
+ tristate "IT8761E GPIO support"
+ depends on GPIOLIB
+ help
+ Say yes here to support GPIO functionality of IT8761E super I/O chip.
+
comment "I2C GPIO expanders:"

config GPIO_MAX732X
diff -Nru linux-2.6.33-rc7.orig/drivers/gpio/Makefile linux-2.6.33-rc7/drivers/gpio/Makefile
--- linux-2.6.33-rc7.orig/drivers/gpio/Makefile 2010-02-07 00:17:12.000000000 +0200
+++ linux-2.6.33-rc7/drivers/gpio/Makefile 2010-02-17 18:53:15.000000000 +0200
@@ -22,3 +22,4 @@
obj-$(CONFIG_GPIO_BT8XX) += bt8xxgpio.o
obj-$(CONFIG_GPIO_VR41XX) += vr41xx_giu.o
obj-$(CONFIG_GPIO_WM831X) += wm831x-gpio.o
+obj-$(CONFIG_GPIO_IT8761E) += it8761e_gpio.o
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Documentation: remove obsolete voyager.txt file
http://groups.google.com/group/linux.kernel/t/2568fc504a3bffe5?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:20 am
From: Bartlomiej Zolnierkiewicz

x86/Voyager support has been removed a year ago.

Inspired-by: Jonathan Corbet <corbet@lwn.net>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
Documentation/voyager.txt | 95 ----------------------------------------------
1 file changed, 95 deletions(-)

Index: b/Documentation/voyager.txt
===================================================================
--- a/Documentation/voyager.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-Running Linux on the Voyager Architecture
-=========================================
-
-For full details and current project status, see
-
-http://www.hansenpartnership.com/voyager
-
-The voyager architecture was designed by NCR in the mid 80s to be a
-fully SMP capable RAS computing architecture built around intel's 486
-chip set. The voyager came in three levels of architectural
-sophistication: 3,4 and 5 --- 1 and 2 never made it out of prototype.
-The linux patches support only the Level 5 voyager architecture (any
-machine class 3435 and above).
-
-The Voyager Architecture
-------------------------
-
-Voyager machines consist of a Baseboard with a 386 diagnostic
-processor, a Power Supply Interface (PSI) a Primary and possibly
-Secondary Microchannel bus and between 2 and 20 voyager slots. The
-voyager slots can be populated with memory and cpu cards (up to 4GB
-memory and from 1 486 to 32 Pentium Pro processors). Internally, the
-voyager has a dual arbitrated system bus and a configuration and test
-bus (CAT). The voyager bus speed is 40MHz. Therefore (since all
-voyager cards are dual ported for each system bus) the maximum
-transfer rate is 320Mb/s but only if you have your slot configuration
-tuned (only memory cards can communicate with both busses at once, CPU
-cards utilise them one at a time).
-
-Voyager SMP
------------
-
-Since voyager was the first intel based SMP system, it is slightly
-more primitive than the Intel IO-APIC approach to SMP. Voyager allows
-arbitrary interrupt routing (including processor affinity routing) of
-all 16 PC type interrupts. However it does this by using a modified
-5259 master/slave chip set instead of an APIC bus. Additionally,
-voyager supports Cross Processor Interrupts (CPI) equivalent to the
-APIC IPIs. There are two routed voyager interrupt lines provided to
-each slot.
-
-Processor Cards
----------------
-
-These come in single, dyadic and quad configurations (the quads are
-problematic--see later). The maximum configuration is 8 quad cards
-for 32 way SMP.
-
-Quad Processors
----------------
-
-Because voyager only supplies two interrupt lines to each Processor
-card, the Quad processors have to be configured (and Bootstrapped) in
-as a pair of Master/Slave processors.
-
-In fact, most Quad cards only accept one VIC interrupt line, so they
-have one interrupt handling processor (called the VIC extended
-processor) and three non-interrupt handling processors.
-
-Current Status
---------------
-
-The System will boot on Mono, Dyad and Quad cards. There was
-originally a Quad boot problem which has been fixed by proper gdt
-alignment in the initial boot loader. If you still cannot get your
-voyager system to boot, email me at:
-
-<J.E.J.Bottomley@HansenPartnership.com>
-
-
-The Quad cards now support using the separate Quad CPI vectors instead
-of going through the VIC mailbox system.
-
-The Level 4 architecture (3430 and 3360 Machines) should also work
-fine.
-
-Dump Switch
------------
-
-The voyager dump switch sends out a broadcast NMI which the voyager
-code intercepts and does a task dump.
-
-Power Switch
-------------
-
-The front panel power switch is intercepted by the kernel and should
-cause a system shutdown and power off.
-
-A Note About Mixed CPU Systems
-------------------------------
-
-Linux isn't designed to handle mixed CPU systems very well. In order
-to get everything going you *must* make sure that your lowest
-capability CPU is used for booting. Also, mixing CPU classes
-(e.g. 486 and 586) is really not going to work very well at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: linux-next: manual merge of the als tree with Linus' tree
http://groups.google.com/group/linux.kernel/t/d4da49591502cde8?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:20 am
From: Jonathan Cameron

On 02/18/10 06:11, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the als tree got a conflict in drivers/misc/Kconfig between commit 8c5d30e590593495c5bb8bd4a2519ce1ac909a22 ("dell-laptop: remove duplicate Kconfig entry under drivers/misc") from Linus' tree and commit 6600f58cfc348ef5862876ab4965d95aad793429 ("isl29003: Move from misc to als now it available with minimal changes") from the als tree.
>
> Just context changes. I fixed it up (see below) and can carry the change
> for a while.
Thanks Stephen and sorry for wasting your time!

I've reset that last patch, merged Linus' current tree and reapplied it on top with the
merge problems fixed up. While I was there I edited the commit message so it was actually
English (oops).

Anyhow, (fingers crossed), it should now work fine.

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: x86-32: use SSE for atomic64_read/set if available
http://groups.google.com/group/linux.kernel/t/c7fe1bc8eb70e0f9?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 18 2010 7:30 am
From: "H. Peter Anvin"

On 02/18/2010 02:27 AM, Luca Barbieri wrote:
>> CR changes are slow and synchronize the CPU. The later is always slow.
>>
>> It sounds like you didn't time it?
> I didn't, because I think it strongly depends on the microarchitecture
> and I don't have a comprehensive set of machines to test on, so it
> would just be a single data point.
>
> The lock prefix on cmpxchg8b is also serializing so it might be as bad.

No. LOCK isn't serializing in the same way CRx writes are.

> Anyway, if we use this, we should keep TS cleared in kernel mode and
> lazily restore it on return to userspace.
> This would make clts/stts performance mostly moot.

This is what kernel_fpu_begin/kernel_fpu_end is all about. We
definitely cannot leave TS cleared without the user space CPU state
moved to its home location, or we have yet another complicated state to
worry about.

I really feel that without a *strong* use case for this, there is
absolutely no point.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

== 2 of 2 ==
Date: Thurs, Feb 18 2010 7:30 am
From: "H. Peter Anvin"

On 02/18/2010 02:25 AM, Peter Zijlstra wrote:
> On Wed, 2010-02-17 at 12:42 +0100, Luca Barbieri wrote:
>> This patch makes atomic64 use either the generic implementation or
>> the rewritten cmpxchg8b one just introduced by inserting a "call" to
>> either, using the alternatives system to dynamically switch the calls.
>>
>> This allows to use atomic64_t on 386/486 which lack cmpxchg8b
>
> IIRC we dropped <i586 SMP support, and since we don't have a PMU on
> those chips atomic64_t doesn't need to be NMI safe, so a simple
> UP-IRQ-disable implementation should suffice.

... which is what we have now, with the cmpxchg8b alternates emulation.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

==============================================================================
TOPIC: Export unusable free space index via /proc/pagetypeinfo
http://groups.google.com/group/linux.kernel/t/8f3afebfb2eb60df?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 18 2010 7:30 am
From: Minchan Kim

On Fri, 2010-02-12 at 12:00 +0000, Mel Gorman wrote:
> Unusuable free space index is a measure of external fragmentation that
> takes the allocation size into account. For the most part, the huge page
> size will be the size of interest but not necessarily so it is exported
> on a per-order and per-zone basis via /proc/pagetypeinfo.
>
> The index is normally calculated as a value between 0 and 1 which is
> obviously unsuitable within the kernel. Instead, the first three decimal
> places are used as a value between 0 and 1000 for an integer approximation.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>

There are comments at below.
It's very trivial so I don't care.

> ---
> Documentation/filesystems/proc.txt | 10 ++++
> mm/vmstat.c | 99 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 109 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index 1829dfb..0968a81 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -614,6 +614,10 @@ Node 0, zone DMA32, type Movable 169 152 113 91 77
> Node 0, zone DMA32, type Reserve 1 2 2 2 2 0 1 1 1 1 0
> Node 0, zone DMA32, type Isolate 0 0 0 0 0 0 0 0 0 0 0
>
> +Unusable free space index at order
> +Node 0, zone DMA 0 0 0 2 6 18 34 67 99 227 485
> +Node 0, zone DMA32 0 0 1 2 4 7 10 17 23 31 34
> +
> Number of blocks type Unmovable Reclaimable Movable Reserve Isolate
> Node 0, zone DMA 2 0 5 1 0
> Node 0, zone DMA32 41 6 967 2 0
> @@ -629,6 +633,12 @@ then gives the same type of information as buddyinfo except broken down
> by migrate-type and finishes with details on how many page blocks of each
> type exist.
>
> +The unusable free space index measures how much of the available free
> +memory cannot be used to satisfy an allocation of a given size and is a
> +value between 0 and 1000. The higher the value, the more of free memory is
> +unusable and by implication, the worse the external fragmentation is. The
> +percentage of unusable free memory can be found by dividing this value by 10.
> +
> If min_free_kbytes has been tuned correctly (recommendations made by hugeadm
> from libhugetlbfs http://sourceforge.net/projects/libhugetlbfs/), one can
> make an estimate of the likely number of huge pages that can be allocated
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index 6051fba..d05d610 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -451,6 +451,104 @@ static int frag_show(struct seq_file *m, void *arg)
> return 0;
> }
>
> +
> +struct contig_page_info {
> + unsigned long free_pages;
> + unsigned long free_blocks_total;
> + unsigned long free_blocks_suitable;
> +};
> +
> +/*
> + * Calculate the number of free pages in a zone, how many contiguous
> + * pages are free and how many are large enough to satisfy an allocation of
> + * the target size. Note that this function makes to attempt to estimate
> + * how many suitable free blocks there *might* be if MOVABLE pages were
> + * migrated. Calculating that is possible, but expensive and can be
> + * figured out from userspace
> + */
> +static void fill_contig_page_info(struct zone *zone,
> + unsigned int suitable_order,
> + struct contig_page_info *info)
> +{
> + unsigned int order;
> +
> + info->free_pages = 0;
> + info->free_blocks_total = 0;
> + info->free_blocks_suitable = 0;
> +
> + for (order = 0; order < MAX_ORDER; order++) {
> + unsigned long blocks;
> +
> + /* Count number of free blocks */
> + blocks = zone->free_area[order].nr_free;
> + info->free_blocks_total += blocks;
> +
> + /* Count free base pages */
> + info->free_pages += blocks << order;
> +
> + /* Count the suitable free blocks */
> + if (order >= suitable_order)
> + info->free_blocks_suitable += blocks <<
> + (order - suitable_order);
> + }
> +}
> +
> +/*
> + * Return an index indicating how much of the available free memory is
> + * unusable for an allocation of the requested size.
> + */
> +static int unusable_free_index(struct zone *zone,

Did you remain "zone" argument for later?
Anyway, It's trivial.

> + unsigned int order,
> + struct contig_page_info *info)
> +{
> + /* No free memory is interpreted as all free memory is unusable */
> + if (info->free_pages == 0)
> + return 1000;
> +
> + /*
> + * Index should be a value between 0 and 1. Return a value to 3
> + * decimal places.
> + *
> + * 0 => no fragmentation
> + * 1 => high fragmentation
> + */
> + return ((info->free_pages - (info->free_blocks_suitable << order)) * 1000) / info->free_pages;
> +
> +}
> +
> +static void pagetypeinfo_showunusable_print(struct seq_file *m,
> + pg_data_t *pgdat, struct zone *zone)
> +{
> + unsigned int order;
> +
> + /* Alloc on stack as interrupts are disabled for zone walk */

contig_page_info would be larger than now?
I think it's small data now. I don't know why you comment it.
It's just out of curiosity. :)

> + struct contig_page_info info;
> +
> + seq_printf(m, "Node %4d, zone %8s %19s",
> + pgdat->node_id,
> + zone->name, " ");
> + for (order = 0; order < MAX_ORDER; ++order) {
> + fill_contig_page_info(zone, order, &info);
> + seq_printf(m, "%6d ", unusable_free_index(zone, order, &info));
> + }
> +
> + seq_putc(m, '\n');
> +}
> +
> +/*
> + * Display unusable free space index
> + * XXX: Could be a lot more efficient, but it's not a critical path
> + */
> +static int pagetypeinfo_showunusable(struct seq_file *m, void *arg)
> +{
> + pg_data_t *pgdat = (pg_data_t *)arg;
> +
> + seq_printf(m, "\nUnusable free space index at order\n");
> + walk_zones_in_node(m, pgdat, pagetypeinfo_showunusable_print);
> +
> + return 0;
> +}
> +
> static void pagetypeinfo_showfree_print(struct seq_file *m,
> pg_data_t *pgdat, struct zone *zone)
> {
> @@ -558,6 +656,7 @@ static int pagetypeinfo_show(struct seq_file *m, void *arg)
> seq_printf(m, "Pages per block: %lu\n", pageblock_nr_pages);
> seq_putc(m, '\n');
> pagetypeinfo_showfree(m, pgdat);
> + pagetypeinfo_showunusable(m, pgdat);
> pagetypeinfo_showblockcount(m, pgdat);
>
> return 0;

--
Kind regards,
Minchan Kim

== 2 of 2 ==
Date: Thurs, Feb 18 2010 7:40 am
From: Mel Gorman

On Fri, Feb 19, 2010 at 12:23:59AM +0900, Minchan Kim wrote:
> On Fri, 2010-02-12 at 12:00 +0000, Mel Gorman wrote:
> > Unusuable free space index is a measure of external fragmentation that
> > takes the allocation size into account. For the most part, the huge page
> > size will be the size of interest but not necessarily so it is exported
> > on a per-order and per-zone basis via /proc/pagetypeinfo.
> >
> > The index is normally calculated as a value between 0 and 1 which is
> > obviously unsuitable within the kernel. Instead, the first three decimal
> > places are used as a value between 0 and 1000 for an integer approximation.
> >
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
>
> There are comments at below.
> It's very trivial so I don't care.
>

Thanks

> > ---
> > Documentation/filesystems/proc.txt | 10 ++++
> > mm/vmstat.c | 99 ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 109 insertions(+), 0 deletions(-)
> >
> > diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> > index 1829dfb..0968a81 100644
> > --- a/Documentation/filesystems/proc.txt
> > +++ b/Documentation/filesystems/proc.txt
> > @@ -614,6 +614,10 @@ Node 0, zone DMA32, type Movable 169 152 113 91 77
> > Node 0, zone DMA32, type Reserve 1 2 2 2 2 0 1 1 1 1 0
> > Node 0, zone DMA32, type Isolate 0 0 0 0 0 0 0 0 0 0 0
> >
> > +Unusable free space index at order
> > +Node 0, zone DMA 0 0 0 2 6 18 34 67 99 227 485
> > +Node 0, zone DMA32 0 0 1 2 4 7 10 17 23 31 34
> > +
> > Number of blocks type Unmovable Reclaimable Movable Reserve Isolate
> > Node 0, zone DMA 2 0 5 1 0
> > Node 0, zone DMA32 41 6 967 2 0
> > @@ -629,6 +633,12 @@ then gives the same type of information as buddyinfo except broken down
> > by migrate-type and finishes with details on how many page blocks of each
> > type exist.
> >
> > +The unusable free space index measures how much of the available free
> > +memory cannot be used to satisfy an allocation of a given size and is a
> > +value between 0 and 1000. The higher the value, the more of free memory is
> > +unusable and by implication, the worse the external fragmentation is. The
> > +percentage of unusable free memory can be found by dividing this value by 10.
> > +
> > If min_free_kbytes has been tuned correctly (recommendations made by hugeadm
> > from libhugetlbfs http://sourceforge.net/projects/libhugetlbfs/), one can
> > make an estimate of the likely number of huge pages that can be allocated
> > diff --git a/mm/vmstat.c b/mm/vmstat.c
> > index 6051fba..d05d610 100644
> > --- a/mm/vmstat.c
> > +++ b/mm/vmstat.c
> > @@ -451,6 +451,104 @@ static int frag_show(struct seq_file *m, void *arg)
> > return 0;
> > }
> >
> > +
> > +struct contig_page_info {
> > + unsigned long free_pages;
> > + unsigned long free_blocks_total;
> > + unsigned long free_blocks_suitable;
> > +};
> > +
> > +/*
> > + * Calculate the number of free pages in a zone, how many contiguous
> > + * pages are free and how many are large enough to satisfy an allocation of
> > + * the target size. Note that this function makes to attempt to estimate
> > + * how many suitable free blocks there *might* be if MOVABLE pages were
> > + * migrated. Calculating that is possible, but expensive and can be
> > + * figured out from userspace
> > + */
> > +static void fill_contig_page_info(struct zone *zone,
> > + unsigned int suitable_order,
> > + struct contig_page_info *info)
> > +{
> > + unsigned int order;
> > +
> > + info->free_pages = 0;
> > + info->free_blocks_total = 0;
> > + info->free_blocks_suitable = 0;
> > +
> > + for (order = 0; order < MAX_ORDER; order++) {
> > + unsigned long blocks;
> > +
> > + /* Count number of free blocks */
> > + blocks = zone->free_area[order].nr_free;
> > + info->free_blocks_total += blocks;
> > +
> > + /* Count free base pages */
> > + info->free_pages += blocks << order;
> > +
> > + /* Count the suitable free blocks */
> > + if (order >= suitable_order)
> > + info->free_blocks_suitable += blocks <<
> > + (order - suitable_order);
> > + }
> > +}
> > +
> > +/*
> > + * Return an index indicating how much of the available free memory is
> > + * unusable for an allocation of the requested size.
> > + */
> > +static int unusable_free_index(struct zone *zone,
>
> Did you remain "zone" argument for later?
> Anyway, It's trivial.
>

It's an oversight. I'll remove the parameter as unnecessary. It was
needed in an earlier iteration.

> > + unsigned int order,
> > + struct contig_page_info *info)
> > +{
> > + /* No free memory is interpreted as all free memory is unusable */
> > + if (info->free_pages == 0)
> > + return 1000;
> > +
> > + /*
> > + * Index should be a value between 0 and 1. Return a value to 3
> > + * decimal places.
> > + *
> > + * 0 => no fragmentation
> > + * 1 => high fragmentation
> > + */
> > + return ((info->free_pages - (info->free_blocks_suitable << order)) * 1000) / info->free_pages;
> > +
> > +}
> > +
> > +static void pagetypeinfo_showunusable_print(struct seq_file *m,
> > + pg_data_t *pgdat, struct zone *zone)
> > +{
> > + unsigned int order;
> > +
> > + /* Alloc on stack as interrupts are disabled for zone walk */
>
> contig_page_info would be larger than now?
> I think it's small data now. I don't know why you comment it.
> It's just out of curiosity. :)
>

It is small data. I don't remember why I felt the need to spell out why
I didn't use kmalloc(). I'll drop the comment as it's not very helpful.

>
> > + struct contig_page_info info;
> > +
> > + seq_printf(m, "Node %4d, zone %8s %19s",
> > + pgdat->node_id,
> > + zone->name, " ");
> > + for (order = 0; order < MAX_ORDER; ++order) {
> > + fill_contig_page_info(zone, order, &info);
> > + seq_printf(m, "%6d ", unusable_free_index(zone, order, &info));
> > + }
> > +
> > + seq_putc(m, '\n');
> > +}
> > +
> > +/*
> > + * Display unusable free space index
> > + * XXX: Could be a lot more efficient, but it's not a critical path
> > + */
> > +static int pagetypeinfo_showunusable(struct seq_file *m, void *arg)
> > +{
> > + pg_data_t *pgdat = (pg_data_t *)arg;
> > +
> > + seq_printf(m, "\nUnusable free space index at order\n");
> > + walk_zones_in_node(m, pgdat, pagetypeinfo_showunusable_print);
> > +
> > + return 0;
> > +}
> > +
> > static void pagetypeinfo_showfree_print(struct seq_file *m,
> > pg_data_t *pgdat, struct zone *zone)
> > {
> > @@ -558,6 +656,7 @@ static int pagetypeinfo_show(struct seq_file *m, void *arg)
> > seq_printf(m, "Pages per block: %lu\n", pageblock_nr_pages);
> > seq_putc(m, '\n');
> > pagetypeinfo_showfree(m, pgdat);
> > + pagetypeinfo_showunusable(m, pgdat);
> > pagetypeinfo_showblockcount(m, pgdat);
> >
> > return 0;
>
>
> --
> Kind regards,
> Minchan Kim
>
>

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Uncool feature for TTM introduced by x86, pat: Use page flags to track
memtypes of RAM pages
http://groups.google.com/group/linux.kernel/t/e6028262be4092ae?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:40 am
From: Jerome Glisse

Hi,

commit id: f58417409603d62f2eb23db4d2cf6853d84a1698

TTM is doing uncommon use of set_memory_wc|uc|wb for instance it's not
uncommon for TTM to change memory type from wc to uc or from uc to wc.
Since x86, pat: Use page flags to track memtypes of RAM pages (commit
id above) this isn't allowed anymore, before going from uc to wc or
wc to uc we first have to free the memtype by going through wb this
means an extra step which likely lead to some overhead (i guess that
uc -> wc or wc -> uc won't trigger massive tlb/cpu flush while
uc -> wb -> wc or wc -> wb -> uc will). reserve_ram_pages_type is the
function which will check that memory is wb thus enforcing us to go
through wb step.

Can we modify the interface to support again changing from uc to wc
or wc to uc ? (i can try to do a patch for that).

If no, we have a sever regression on non PAT arch :
http://bugzilla.kernel.org/show_bug.cgi?id=15328
(AFAIK bugzilla.kernel.org is down for me at the moment) because we
are doing the extra set wb step (i haven't dived deep into the code
to check what happen on non PAT). My guess is that on non PAT the
extra set wb can be avoided right ? Also what is your educated guess
on why on non PAT this extra set wb is slowing down thing badly ?
Last can we make this extra step only on PAT enabled arch ?

In PAT case right now we are calling get get_page_memtype to know
if we need to set page to wb first my understanding is that we should
protect this call by memtype_lock spinlock (even if i don't think we
can have collision here as we are protected by TTM locking), maybe
we can directly use TTM information to call or not set wb and avoid
using get_page_memtype.

Sorry for being such annoying user of PAT, i guess GPU is the only
place having such strange and intensive cache change pattern.

Cheers,
Jerome
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Export fragmentation index via /proc/pagetypeinfo
http://groups.google.com/group/linux.kernel/t/c8c288ab151c09bb?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:40 am
From: Minchan Kim

On Fri, 2010-02-12 at 12:00 +0000, Mel Gorman wrote:
> Fragmentation index is a value that makes sense when an allocation of a
> given size would fail. The index indicates whether an allocation failure is
> due to a lack of memory (values towards 0) or due to external fragmentation
> (value towards 1). For the most part, the huge page size will be the size
> of interest but not necessarily so it is exported on a per-order and per-zone
> basis via /proc/pagetypeinfo.
>
> The index is normally calculated as a value between 0 and 1 which is
> obviously unsuitable within the kernel. Instead, the first three decimal
> places are used as a value between 0 and 1000 for an integer approximation.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>

> ---
> Documentation/filesystems/proc.txt | 11 ++++++
> mm/vmstat.c | 63 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 74 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
> index 0968a81..06bf53c 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -618,6 +618,10 @@ Unusable free space index at order
> Node 0, zone DMA 0 0 0 2 6 18 34 67 99 227 485
> Node 0, zone DMA32 0 0 1 2 4 7 10 17 23 31 34
>
> +Fragmentation index at order
> +Node 0, zone DMA -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
> +Node 0, zone DMA32 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
> +
> Number of blocks type Unmovable Reclaimable Movable Reserve Isolate
> Node 0, zone DMA 2 0 5 1 0
> Node 0, zone DMA32 41 6 967 2 0
> @@ -639,6 +643,13 @@ value between 0 and 1000. The higher the value, the more of free memory is
> unusable and by implication, the worse the external fragmentation is. The
> percentage of unusable free memory can be found by dividing this value by 10.
>
> +The fragmentation index, is only meaningful if an allocation would fail and
> +indicates what the failure is due to. A value of -1 such as in the example
> +states that the allocation would succeed. If it would fail, the value is
> +between 0 and 1000. A value tending towards 0 implies the allocation failed
> +due to a lack of memory. A value tending towards 1000 implies it failed
> +due to external fragmentation.
> +
> If min_free_kbytes has been tuned correctly (recommendations made by hugeadm
> from libhugetlbfs http://sourceforge.net/projects/libhugetlbfs/), one can
> make an estimate of the likely number of huge pages that can be allocated
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index d05d610..e2d0cc1 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -494,6 +494,35 @@ static void fill_contig_page_info(struct zone *zone,
> }
>
> /*
> + * A fragmentation index only makes sense if an allocation of a requested
> + * size would fail. If that is true, the fragmentation index indicates
> + * whether external fragmentation or a lack of memory was the problem.
> + * The value can be used to determine if page reclaim or compaction
> + * should be used
> + */
> +int fragmentation_index(struct zone *zone,

Like previous [3/12], why do you remain "zone" argument?
If you will use it in future, I don't care. It's just trivial.

--
Kind regards,
Minchan Kim

==============================================================================
TOPIC: Loan Offer
http://groups.google.com/group/linux.kernel/t/8de9d77f99f99e86?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 18 2010 7:40 am
From: Cesar Augusto

I am Cesar Augusto of Cesar Augusto® Corporation.
We give out loans to business people and individuals for just 3% interest
rate.We give out local and international loan via account transfer to
qualified
borrowers.

If you are interested in getting loan from our company,contact us with the
following details to help us send you our loan terms and repayment Plan.

===========================
FIRST NAME:...........
LAST NAME:.......
ADDRESS:................
COUNTRY:..............
PHONE NUMBER:.........
FAX NUMBER: ...........
OCCUPATION:...........
MONTHLY INCOME...........
AGE:...............
LOAN AMOUNT NEEDED:.......
LOAN DURATION:........
=============================
Mode of Payment:
* Payment by bank to bank transfer
=============================

Regards,
Cesar Augusto.
Email: cesaraugusto@qatar.io

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Thursday, February 18, 2010

linux.kernel - 26 new messages in 16 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts