* Re: [PATCH] net: add sysctl allow_so_priority for SO_PRIORITY setsockopt
From: David Miller @ 2011-10-22 8:40 UTC (permalink / raw)
To: zenczykowski; +Cc: netdev
In-Reply-To: <CAHo-OoyVSbsxb8U3Y5WCNRsxjr00g1O3HJcT1fmu5cmP5i-JsA@mail.gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Sat, 22 Oct 2011 01:27:03 -0700
> I am attempting to allow not-fully-code-audited nor fully trusted apps to run
> in a cgroup containerized environment, with many apps in many
> containers (not 1:1, has hierarchies) on a single kernel.
Extend, if necessary, the cgroup classifier so you can use it to clip
off the socket inherited priority in the SKB for this cgroup.
Really, this control has no business in the socket API layer.
^ permalink raw reply
* Re: BUG: All network processes hang (brcmsmac/wpa_supplicant)
From: Greg KH @ 2011-10-22 8:30 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Nico Schottelius, Eric Dumazet, LKML,
linux-wireless@vger.kernel.org
In-Reply-To: <400C43189542CE41BC0A5B252FC90136BC0E147BCB@SJEXCHCCR02.corp.ad.broadcom.com>
On Sat, Oct 22, 2011 at 01:13:34AM -0700, Arend Van Spriel wrote:
> > From: Nico Schottelius [mailto:nico-linux-20111017@schottelius.org]
> > Sent: zaterdag 22 oktober 2011 4:00
> >
> > Hey Arend,
> >
> > it seems that your patch really solves this problem.
>
> Great. This fix is in linux-next tree.
>
> Greg,
>
> This problem causes packets to get dropped on 5GHz. Should I
> sent a patch for 3.1 (staging-linus) for this? It is already
> fixed in wireless-next.
No, just wait for it to get into Linus's tree for 3.2-rc1, and then
email the git commit id to stable@vger.kernel.org so it will be added to
the 3.1-stable releases.
greg k-h
^ permalink raw reply
* [PATCH 2/2] vmwgfx: Don't pass unused arguments to do_dirty functions
From: Thomas Hellstrom @ 2011-10-22 8:29 UTC (permalink / raw)
To: airlied; +Cc: Thomas Hellstrom, dri-devel
In-Reply-To: <1319272174-13368-1-git-send-email-thellstrom@vmware.com>
From: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 00ec619..8b14dfd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -353,7 +353,6 @@ void vmw_framebuffer_surface_destroy(struct drm_framebuffer *framebuffer)
static int do_surface_dirty_sou(struct vmw_private *dev_priv,
struct drm_file *file_priv,
struct vmw_framebuffer *framebuffer,
- struct vmw_surface *surf,
unsigned flags, unsigned color,
struct drm_clip_rect *clips,
unsigned num_clips, int inc)
@@ -381,7 +380,6 @@ static int do_surface_dirty_sou(struct vmw_private *dev_priv,
units[num_units++] = vmw_crtc_to_du(crtc);
}
- BUG_ON(surf == NULL);
BUG_ON(!clips || !num_clips);
fifo_size = sizeof(*cmd) + sizeof(SVGASignedRect) * num_clips;
@@ -476,7 +474,6 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer *framebuffer,
struct vmw_master *vmaster = vmw_master(file_priv->master);
struct vmw_framebuffer_surface *vfbs =
vmw_framebuffer_to_vfbs(framebuffer);
- struct vmw_surface *surf = vfbs->surface;
struct drm_clip_rect norect;
int ret, inc = 1;
@@ -502,7 +499,7 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer *framebuffer,
inc = 2; /* skip source rects */
}
- ret = do_surface_dirty_sou(dev_priv, file_priv, &vfbs->base, surf,
+ ret = do_surface_dirty_sou(dev_priv, file_priv, &vfbs->base,
flags, color,
clips, num_clips, inc);
@@ -642,7 +639,6 @@ void vmw_framebuffer_dmabuf_destroy(struct drm_framebuffer *framebuffer)
static int do_dmabuf_dirty_ldu(struct vmw_private *dev_priv,
struct vmw_framebuffer *framebuffer,
- struct vmw_dma_buffer *buffer,
unsigned flags, unsigned color,
struct drm_clip_rect *clips,
unsigned num_clips, int increment)
@@ -722,7 +718,6 @@ static int do_dmabuf_define_gmrfb(struct drm_file *file_priv,
static int do_dmabuf_dirty_sou(struct drm_file *file_priv,
struct vmw_private *dev_priv,
struct vmw_framebuffer *framebuffer,
- struct vmw_dma_buffer *buffer,
unsigned flags, unsigned color,
struct drm_clip_rect *clips,
unsigned num_clips, int increment)
@@ -811,7 +806,6 @@ int vmw_framebuffer_dmabuf_dirty(struct drm_framebuffer *framebuffer,
struct vmw_master *vmaster = vmw_master(file_priv->master);
struct vmw_framebuffer_dmabuf *vfbd =
vmw_framebuffer_to_vfbd(framebuffer);
- struct vmw_dma_buffer *dmabuf = vfbd->buffer;
struct drm_clip_rect norect;
int ret, increment = 1;
@@ -831,12 +825,12 @@ int vmw_framebuffer_dmabuf_dirty(struct drm_framebuffer *framebuffer,
}
if (dev_priv->ldu_priv) {
- ret = do_dmabuf_dirty_ldu(dev_priv, &vfbd->base, dmabuf,
+ ret = do_dmabuf_dirty_ldu(dev_priv, &vfbd->base,
flags, color,
clips, num_clips, increment);
} else {
ret = do_dmabuf_dirty_sou(file_priv, dev_priv, &vfbd->base,
- dmabuf, flags, color,
+ flags, color,
clips, num_clips, increment);
}
--
1.7.4.4
^ permalink raw reply related
* [PATCH 1/2] vmwgfx: Emulate depth 32 framebuffers
From: Thomas Hellstrom @ 2011-10-22 8:29 UTC (permalink / raw)
To: airlied; +Cc: Thomas Hellstrom, dri-devel
From: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 39b99db..00ec619 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -679,6 +679,7 @@ static int do_dmabuf_define_gmrfb(struct drm_file *file_priv,
struct vmw_private *dev_priv,
struct vmw_framebuffer *framebuffer)
{
+ int depth = framebuffer->base.depth;
size_t fifo_size;
int ret;
@@ -687,6 +688,13 @@ static int do_dmabuf_define_gmrfb(struct drm_file *file_priv,
SVGAFifoCmdDefineGMRFB body;
} *cmd;
+ /* Emulate RGBA support, contrary to svga_reg.h this is not
+ * supported by hosts. This is only a problem if we are reading
+ * this value later and expecting what we uploaded back.
+ */
+ if (depth == 32)
+ depth = 24;
+
fifo_size = sizeof(*cmd);
cmd = kmalloc(fifo_size, GFP_KERNEL);
if (unlikely(cmd == NULL)) {
@@ -697,7 +705,7 @@ static int do_dmabuf_define_gmrfb(struct drm_file *file_priv,
memset(cmd, 0, fifo_size);
cmd->header = SVGA_CMD_DEFINE_GMRFB;
cmd->body.format.bitsPerPixel = framebuffer->base.bits_per_pixel;
- cmd->body.format.colorDepth = framebuffer->base.depth;
+ cmd->body.format.colorDepth = depth;
cmd->body.format.reserved = 0;
cmd->body.bytesPerLine = framebuffer->base.pitch;
cmd->body.ptr.gmrId = framebuffer->user_handle;
--
1.7.4.4
^ permalink raw reply related
* [U-Boot] [PATCH v4 2/2] NS16550: buffer reads
From: Albert ARIBAUD @ 2011-10-22 8:29 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ3qJw9WoZdfR9i8O=dS-gnV_iDCr8FKh7zNnqx=jJ8YMQ@mail.gmail.com>
Le 17/10/2011 22:58, Simon Glass a ?crit :
> Hi Wolfgang,
>
> On Mon, Oct 17, 2011 at 1:33 PM, Wolfgang Denk<wd@denx.de> wrote:
>> Dear Simon Glass,
>>
>> In message<CAPnjgZ1412ezJh3f4Ww16k4Z55kJdgGWj7+vMyK_ot-MzVd70g@mail.gmail.com> you wrote:
>>>
>>> Can you please tell me which ELDK version this is using? I see that
>>> the 405 board seems to need ppc_4xx which suggests 4.2 rather than 5,
>>> since in 5 the compiler is called powerpc-
>>
>> Right, I was testing this with ELDK 4.2.
>
> I am struggling to repeat this and don't even get the same numbers...
Could be due to two things:
1) both of you do not work from the same exact tree commit, or
2) both of you work in a different base directory
> For your AR405 board, you saw:
>> - 246058 12972 14636 273666 42d02 /work/wd/tmp-ppc/u-boot
>> + 246062 12972 14636 273670 42d06 /work/wd/tmp-ppc/u-boot
> For me:
> 245942 12964 14632 273538 42c82 ppc/u-boot
I suggest Wolfgang and you compare your trees to eliminate risk 1, and
make sure you compare .bin files to reduce risk 2.
Amicalement,
--
Albert.
^ permalink raw reply
* Re: [PATCH 00/36] Staging: cx25821: Clean up patch series
From: Greg KH @ 2011-10-22 8:19 UTC (permalink / raw)
To: Leonid V. Fedorenchik
Cc: Mauro Carvalho Chehab, Namhyung Kim, Palash Bandyopadhyay,
Joe Perches, Ilia Mirkin, Youquan Song, devel, linux-kernel
In-Reply-To: <1319262236-6498-1-git-send-email-leonidsbox@gmail.com>
On Sat, Oct 22, 2011 at 01:43:20PM +0800, Leonid V. Fedorenchik wrote:
> This patch series fixes some style issues in drivers/staging/cx25821
> Mostly I was hoping to improve readability and fix some issues found by
> checkpatch.pl script.
These are for Mauro to take through his tree.
greg k-h
^ permalink raw reply
* Re: [PATCH] net: add sysctl allow_so_priority for SO_PRIORITY setsockopt
From: Maciej Żenczykowski @ 2011-10-22 8:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111022.025836.1306779710775525629.davem@davemloft.net>
> I also don't see why we'd want to allow disabling this either.
> I really hate these patches that offer ways to disable things
> that normally work, and thus break apps when the non-default
> is selected.
Well... the purpose of settings like this is precisely to break functionality
when the default is not set ;-)
> I kind of have a feeling the kind of situation you're trying to
> account for, you have some cloud where people run random stuff
> that you don't control.
Yes, I have control of the kernel, I have control of root, I have control of
some daemons that are running on the machine, but I don't really have
control of the entirety of userspace, some of it I have source code for
and could audit to guarantee correctness (but I can't really enforce
that on the users, ultimately they can run any binary),
and for some of it I don't even have that. Either way, it's much
easier to delegate setting policy to
userspace management daemon(s), and leave enforcing it to the kernel.
This is just one more such knob.
> But you didn't specify this, and we just have to guess. Why don't you
> describe the specific situation where you want to modify this setting?
> Please do this instead of just talking about what the side effects are
> inside of the kernel. That's much less interesting when it comes to
> patches like this.
Very well, that's a good point.
Here's an attempt to provide some insight.
I am attempting to allow not-fully-code-audited nor fully trusted apps to run
in a cgroup containerized environment, with many apps in many
containers (not 1:1, has hierarchies) on a single kernel.
The apps are in the believed to not be actively malicious class, but
very likely to be buggy, or written by ill-advised programmers based
on wrong/outdated or otherwise incorrect documentation. I cannot rely
on unprivileged userspace getting things right.
I have to have some mechanism to grant these apps permissions to
utilize specific levels of network fabric priority. For this I have
the aforementioned per-cgroup allowed TOS settings. VLANs are not appropriate
because a client with high priority net privs is allowed to send a
request to a server with no special priority permissions.
(there are further patches to support tcp tos reflection so the server
can automatically respond with the client's priority)
Multiqueue networking combined with hardware priority queues and xps
desires to use skb->priority + active cpu for tx queue selection.
In this particular case TX queue selection should happen based on the
TOS priority.
Setting TOS automatically sets sk_priority (and hence skb->priority).
So all's good, so long as userspace doesn't go and change the
sk_priority field via SO_PRIORITY and break the mapping.
As a further note:
Some of these apps may be a little more special, a little more
audited, and a little more trusted.
Enough so that they might be granted CAP_NET_RAW, but not enough so
that they can get CAP_NET_ADMIN.
Hence the general desire for CAP_NET_ADMIN to control general
machine-global networking state, but not have it control
per-socket or per-packet settings. ie. bringing up or down an
interface affects everyone (hence must be CAP_NET_ADMIN, and much more
tightly controlled), while spoofing a packet doesn't really negatively
affect anyone (you can't assume the network is trusted, so there can
be
external sources of spoofing or eavesdropping anyway).
---
I could attempt to publish the vast majority of our internal
networking code base (there isn't really anything secret in there),
but it's based on 2.6.34 and even after two years of attempting to
clean it up and refactor it (along with a rebase from 2.6.26, and all
while actively continuing development) I'm still not at the point were
I would consider this to be a particular useful course of action
(there's a lot of bugfixes of bugfixes of crappy patches in there,
plus hacks, plus tons of backports from upstream, and tons of code
which is upstream but slightly differently then we have it internally,
because we had it first, and pushed v2 upstream, etc...). Instead I'm
trying to get the easy hanging fruit out of the way, rebase our
patches onto probably 3.2 or 3.3, likely sending some more your way
during the process, and see where that leaves us. Basically trying to
reduce the delta. We will always have internal only patches, but the
fewer, the less burden for us, hence I'm trying to get the ones I
believe to be potentially useful externally upstreamed. Obviously
whatever patches you don't accept, we'll still keep around locally.
Maciej
^ permalink raw reply
* Re: [PATCH 1/3] Remove race for starting container devices.
From: Jes Sorensen @ 2011-10-22 8:22 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid, lukasz.dorau, adam.kwolek, dledford
In-Reply-To: <20111022114906.2e26e66b@notabene.brown>
On 10/22/11 02:49, NeilBrown wrote:
> Hi Jes,
>
> I have applied the 7 patches you sent.
>
> However I have question mark over part of this one:
>
>
>> > @@ -451,9 +456,10 @@ int Incremental(char *devname, int verbose, int runstop,
>> > devnum = fd2devnum(mdfd);
>> > close(mdfd);
>> > sysfs_free(sra);
>> > - rv = Incremental(chosen_name, verbose, runstop,
>> > - NULL, homehost, require_homehost, autof,
>> > - freeze_reshape);
>> > + rv = Incremental_container(st, chosen_name, homehost,
>> > + verbose, runstop, autof,
>> > + freeze_reshape);
>> > + map_unlock(&map);
>> > if (rv == 1)
>> > /* Don't fail the whole -I if a subarray didn't
>> > * have enough devices to start yet
> You have replaced a call to Incremental with a call to Incremental_container.
> I feel that is significant enough that I would have liked to have seen it
> discussed in the changelog comment.
>
> You seem have have open-coded Incremental and then removed all the bits that
> you don't need in this case - which is that vast majority of it.
> But you didn't include the call to ->load_content().
>
> So I have put it back in because I'm sure it must be harmless (Because it was
> there already) but it may not be needed.
>
> If you have thoughts on this, please let me know.
Hi Neil,
There is a perfectly good explanation for this: The reason is that the
guy who wrote the initial patch is an idiot!
In fact, said idiot spent most of Friday pulling his hairs out trying to
figure out why the modified mdadm would boot fine on a systemd based
system but fail on a sysvinit based system. The result being the patch
bombing you were exposed to yesterday :)
Thanks for catching this, much appreciated!
Jes
^ permalink raw reply
* [U-Boot] [PATCH 0/8] Add tftpput command for uploading files over network
From: Albert ARIBAUD @ 2011-10-22 8:21 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319259100-11376-1-git-send-email-sjg@chromium.org>
Le 22/10/2011 06:51, Simon Glass a ?crit :
> The tftpboot command permits reading of files over a network interface
> using the Trivial FTP protocol. This patch series adds the ability to
> transfer files the other way.
>
> Why is this useful?
>
> - Uploading boot time data to a server
> - Uploading profiling information
> - Uploading large mounts of data for comparison / checking on a host
> (e.g. use tftpput and ghex2 instead of the 'md' command)
Especially I find it interesting for backing up things like MTD and
small disk files (not partitions, though). Most of my work currently is
trying to bring mainline U-Boot support to existing boards with bad
U-Boot implementations, and being able to backup things from U-Boot (as
opposed to having to set up NFS root and Linux boot) would definitely be
a plus.
> Mostly the existing code can be re-used and I have tried to avoid too
> much refactoring or cleaning up.
:)
> The feature is activated by the CONFIG_CMD_TFTPPUT option.
>
> This has been very lightly tested on a Seaboard with a USB network
> adaptor. I don't think it handles block number overflow.
What size does this limit transfers to?
> Simon Glass (8):
> Move simple_itoa to vsprintf
> Add setenv_uint() and setenv_addr()
> tftpput: Rename TFTP to TFTPGET
> tftpput: move common code into separate functions
> tftpput: support selecting get/put for tftp
> tftpput: add save_addr and save_size global variables
> tftpput: implement tftp logic
> tftpput: add tftpput command
Many U-Boot environments use 'tftp' as a shorthand to tftpboot. Did you
verify that this is not broken by the introduction of 'tftpput'?
Also, I'd be happy to test this if a branch exists that already holds
these commits.
Amicalement,
--
Albert.
^ permalink raw reply
* RE: BUG: All network processes hang (brcmsmac/wpa_supplicant)
From: Arend Van Spriel @ 2011-10-22 8:13 UTC (permalink / raw)
To: Nico Schottelius, gregkh@suse.de
Cc: Eric Dumazet, LKML, linux-wireless@vger.kernel.org
In-Reply-To: <20111022015945.GC26186@ethz.ch>
> From: Nico Schottelius [mailto:nico-linux-20111017@schottelius.org]
> Sent: zaterdag 22 oktober 2011 4:00
>
> Hey Arend,
>
> it seems that your patch really solves this problem.
Great. This fix is in linux-next tree.
Greg,
This problem causes packets to get dropped on 5GHz. Should I
sent a patch for 3.1 (staging-linus) for this? It is already
fixed in wireless-next.
> I've got a new one now, though :-)
Ok. Not sure which universal law this is, but let's have a look.
> After several suspend/resume cycles, my card often reconnects to my AP
> that is only several meters (2) away. If the connection is established,
> I've a very laggy connection to the AP:
>
> 64 bytes from 192.168.42.1: icmp_req=1154 ttl=64 time=10839 ms
> 64 bytes from 192.168.42.1: icmp_req=1155 ttl=64 time=9841 ms
> ...
> 64 bytes from 192.168.42.1: icmp_req=1164 ttl=64 time=2814 ms
> 64 bytes from 192.168.42.1: icmp_req=1165 ttl=64 time=16785 ms
> 64 bytes from 192.168.42.1: icmp_req=1166 ttl=64 time=20767 ms
>
> Attached are the usual suspect outputs.
> This time I'm on 2.432 Ghz.
I will dig into it.
Gr. AvS
^ permalink raw reply
* Re: [Qemu-devel] Multi heterogenous CPU archs for SoC sim?
From: 陳韋任 @ 2011-10-22 8:12 UTC (permalink / raw)
To: Andreas
Cc: Peter Maydell, 陳韋任, Lluís,
qemu-devel Developers, Blue Swirl, Greg McGary
In-Reply-To: <4EA1D7E0.9070300@web.de>
> My use case here is testing and debugging, so I think we could live with
> the blocks being executed in an interleaved fashion until someone has
> the ultimate parallelization solution for upstream.
So you prefer parallelizing QEMU itself in your case?
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
^ permalink raw reply
* [PATCH] vfs - fix automount should ignore LOOKUP_FOLLOW
From: Ian Kent @ 2011-10-22 8:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kernel Mailing List, Al Viro, David Howells, Miklos Szeredi
The recent patch by Miklos Szeredi that was meant to restore the original
behavior of not triggering automounts on stat(2) and other symlink following
syscalls also eliminated the unconditional triggering of automounts for
intermediate path components by eliminating the LOOKUP_CONTUNUE flag from
the check in fs/namei.c:follow_automount().
This introduces a regression itself because it alters the original behaviour
which was to unconditionally automount on intermediate path components.
Signed-off-by: Ian Kent <raven@themaw.net>
---
fs/namei.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 0b3138d..e4eee7c 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -732,7 +732,7 @@ static int follow_automount(struct path *path, unsigned flags,
* as being automount points. These will need the attentions
* of the daemon to instantiate them before they can be used.
*/
- if (!(flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY |
+ if (!(flags & (LOOKUP_PARENT | LOOKUP_CONTINUE | LOOKUP_DIRECTORY |
LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT)) &&
path->dentry->d_inode)
return -EISDIR;
^ permalink raw reply related
* Re: [BUG] bonding : LOCKDEP warning
From: David Miller @ 2011-10-22 7:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ebiederm
In-Reply-To: <1319268987.6180.21.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 22 Oct 2011 09:36:27 +0200
> On latest net-next I got following splat
I suspect Biederman's namespace patch set.
Eric B. please take a look.
^ permalink raw reply
* [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
From: Albert ARIBAUD @ 2011-10-22 7:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ2pgLpjNC16jrby_gKOr3uuUn+ubVDYJe0WfAwa8o8jJA@mail.gmail.com>
Le 22/10/2011 07:05, Simon Glass a ?crit :
>>> Well I actually haven't moved it! It is just that previously it was
>>> impossible to call cp15_init from anywhere later.
>>
>> It is moved, in that it belongs to low level init... of A9.
>
> OK, I see - you mean moved in order if not in source code file.
Yes. In the code, though, it belongs to low-level init.
>>> What you say can be done, it would involve some assembler though and
>>> would need to be another CONFIG option. Was trying to avoid adding new
>>> assembler.
>>
>> Low level init is about assembler and, well, low level. :)
>
> Yes but it's yuck. Part of the clean-up is to remove most of the
> assembler - really very little is needed.
I don't think "yuck" is a valid reasoned argument against assembly
language :) but I assume what you mainly mean is 'hard to understand and
replaceable by easy to understand C code'. I agree to the first part,
and to the second one for the general case, but not for the startup path
where, precisely, we don't have a working C run-time and most of the
understanding requires knowledge of hardware, not only general
programming knowledge. Past that, C is ok -- but then beware: some C++
guy could chime in and contend that C is "yuck" by your own standards. :)
>> But I don't see why there should be another CONFIG option. IIUC, you should
>> be able to do with only CONFIG_SKIP_LOWLEVEL_INIT: within the low level init
>> code under it, you would do the equivalent of a switch, with one branch for
>> AVM (and DDR init etc) and one branch for A9 (with cp15 init etc).
>
> Yes I can, but I need to be able to call cp15_init. And I can't do
> that because if CONFIG_SKIP_LOWLEVEL_INIT is defined, that code is
> compiled out! So I need to move that cp15_init code outside the
> CONFIG_SKIP_LOWLEVEL_INIT #ifdef. That is all I am trying to do,
> honest!
I understand, and I think the approach here is wrong, because you *do*
want low-level init in the A9 case, and thus you should not have
CONFIG_SKIP_LOWLEVEL_INIT set. But you also need the AVP low-level init
to be empty, and the AVP and A9 must follow the same startup path. And
all this it not necessarily required for all armv7 platforms, but some
of them will want lowlevel init, and some not. Considering all this...
For now, I would opt for a CONFIG_ARCH_GENERIC_LOWLEVEL_INIT option
which start.S would use to compile out the low level init code
definition (like CONFIG_SKIP_LOWLEVEL_INIT does) but not the the calls
to it (UNline CONFIG_SKIP_LOWLEVEL_INIT does). Then you could provide a
SoC-specific version of lowlevel_init.
In the longer term, I would be more in favor of a weak definition system
with hierarchical ARCH, ISA, SoC, board priority order (yes, I am kind
of fond of it) for lowlevel init -- but that will require looking into
asm weak symbol handling and may require splitting of the assembly code
function by function.
> Regards,
> Simon
Amicalement,
--
Albert.
^ permalink raw reply
* Re: [PATCH] tg3: fix tigon3_dma_hwbug_workaround()
From: Ari Savolainen @ 2011-10-22 7:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: RongQing Li, David Miller, richardcochran, netdev, linux-kernel
In-Reply-To: <1319268338.6180.20.camel@edumazet-laptop>
I tried a similar patch earlier and got another panic with that. I was
quite tired at that time and may have made a mistake. I'll test Eric's
patch either later today or tomorrow.
Ari
2011/10/22 Eric Dumazet <eric.dumazet@gmail.com>:
> Ari got kernel panics using tg3 NIC, and bisected to 2669069aacc9 "tg3:
> enable transmit time stamping."
>
> This is because tigon3_dma_hwbug_workaround() might alloc a new skb and
> free the original. We panic when skb_tx_timestamp() is called on freed
> skb.
>
> Reported-by: Ari Savolainen <ari.m.savolainen@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> drivers/net/tg3.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 4a1374d..6149dc5 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -6029,12 +6029,12 @@ static void tg3_tx_skb_unmap(struct tg3_napi *tnapi, u32 entry, int last)
>
> /* Workaround 4GB and 40-bit hardware DMA bugs. */
> static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
> - struct sk_buff *skb,
> + struct sk_buff **pskb,
> u32 *entry, u32 *budget,
> u32 base_flags, u32 mss, u32 vlan)
> {
> struct tg3 *tp = tnapi->tp;
> - struct sk_buff *new_skb;
> + struct sk_buff *new_skb, *skb = *pskb;
> dma_addr_t new_addr = 0;
> int ret = 0;
>
> @@ -6076,7 +6076,7 @@ static int tigon3_dma_hwbug_workaround(struct tg3_napi *tnapi,
> }
>
> dev_kfree_skb(skb);
> -
> + *pskb = new_skb;
> return ret;
> }
>
> @@ -6305,7 +6305,7 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
> */
> entry = tnapi->tx_prod;
> budget = tg3_tx_avail(tnapi);
> - if (tigon3_dma_hwbug_workaround(tnapi, skb, &entry, &budget,
> + if (tigon3_dma_hwbug_workaround(tnapi, &skb, &entry, &budget,
> base_flags, mss, vlan))
> goto out_unlock;
> }
>
>
>
^ permalink raw reply
* Re: Bug In ext4 in kernels > 2.6.39 - Not mounting with arguments/options I specify in fstab on root remount
From: Matt Parnell @ 2011-10-22 7:53 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Eric Sandeen, linux-ext4
In-Reply-To: <4EA27607.20407@gmail.com>
Also, I didn't intend to come across cross there... I appreciate the
efforts you are taking there.
It's just, I don't know what could've changed between .29 and 3.0 that
would break an entire init system so that it won't remount root rw...
On 10/22/2011 02:51 AM, Matt Parnell wrote:
> That doesn't really help me at all, it's not rootflags=data=writeback
> causing this, it's starting to make me think that arch's init may be
> to blame, although I previously ruled it out...
>
> This is all a big wtf though. I'm going to go complain at the arch
> devs now... I've not finished porting openrc to it yet.
>
> On 10/22/2011 12:00 AM, Ted Ts'o wrote:
>> On Thu, Oct 20, 2011 at 10:29:49PM -0500, Matt Parnell wrote:
>>> The output of /proc/cmdline on 3.0.7:
>>>
>>> BOOT_IMAGE=/boot/vmlinuz26-zen root=/dev/sdb1 ro rootfstype=ext4
>>> rootflags=data=writeback noatime nodiratime barrier=0 discard
>>> noinitrd
>>>
>>>
>>> On 10/09/2011 06:44 PM, Ted Ts'o wrote:
>>>> On Sun, Oct 09, 2011 at 05:10:54PM -0500, Matt Parnell wrote:
>>>>> /proc/mounts (as you can see it's not being remounted rw for some
>>>>> reason - /dev/sdc1 is the flash drive I used to pipe this info onto):
>>>>>
>>>>> rootfs / rootfs rw 0 0
>>>>> /dev/root / ext4 ro,relatime,barrier=1 0 0
>> I haven't had a chance to check on v3.0 (I'm currently travelling and
>> penning this from an airplane), but on v3.1-rc3, it works for me under
>> KVM. I fire up kvm-qemu this way:
>>
>> $QEMU -enable-kvm -boot order=c $NET \
>> -drive file=$ROOT_QCOW2,if=virtio$SNAPSHOT \
>> -drive file=$VDB,cache=none,if=virtio \
>> -drive file=$VDC,cache=none,if=virtio \
>> -drive file=$VDD,cache=none,if=virtio \
>> -nographic -smp $NR_CPU -m $MEM \
>> --kernel $KERNEL \
>> --append "root=/dev/vda console=ttyS0,115200
>> rootflags=data=writeback" |\
>> tee $LOGFILE
>>
>> with this in /proc/cmdline:
>>
>> candygram:~# cat /proc/cmdline
>> root=/dev/vda console=ttyS0,115200 rootflags=data=writeback maint
>>
>> ... and this is what I have in /proc/mounts:
>>
>> candygram:~# head -2 /proc/mounts
>> rootfs / rootfs rw 0 0
>> /dev/root / ext4 rw,noatime,user_xattr,acl,barrier=1,data=writeback 0 0
>>
>> ... and what I have in /etc/fstab:
>>
>> UUID=ce4d6b98-2aa9-42d4-a127-995a795a0b02 / ext4
>> noatime,data=writeback 0 1
>>
>> The kvm image I'm using is using Debian unstable image generated using
>> debootstrap, and uses no modules or initrd's --- which makes it easier
>> for me to boot since $KERNEL is set to:
>>
>> /tyt/linux/ext4/arch/x86/boot/bzImage
>>
>> This allows me to fire up test kernel right from my build tree,
>> without needing to set up any kind of initrd nonsense. :-)
>>
>> - Ted
^ permalink raw reply
* Re: Bug In ext4 in kernels > 2.6.39 - Not mounting with arguments/options I specify in fstab on root remount
From: Matt Parnell @ 2011-10-22 7:51 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Eric Sandeen, linux-ext4
In-Reply-To: <20111022050031.GC4196@thunk.org>
That doesn't really help me at all, it's not rootflags=data=writeback
causing this, it's starting to make me think that arch's init may be to
blame, although I previously ruled it out...
This is all a big wtf though. I'm going to go complain at the arch devs
now... I've not finished porting openrc to it yet.
On 10/22/2011 12:00 AM, Ted Ts'o wrote:
> On Thu, Oct 20, 2011 at 10:29:49PM -0500, Matt Parnell wrote:
>> The output of /proc/cmdline on 3.0.7:
>>
>> BOOT_IMAGE=/boot/vmlinuz26-zen root=/dev/sdb1 ro rootfstype=ext4
>> rootflags=data=writeback noatime nodiratime barrier=0 discard
>> noinitrd
>>
>>
>> On 10/09/2011 06:44 PM, Ted Ts'o wrote:
>>> On Sun, Oct 09, 2011 at 05:10:54PM -0500, Matt Parnell wrote:
>>>> /proc/mounts (as you can see it's not being remounted rw for some
>>>> reason - /dev/sdc1 is the flash drive I used to pipe this info onto):
>>>>
>>>> rootfs / rootfs rw 0 0
>>>> /dev/root / ext4 ro,relatime,barrier=1 0 0
> I haven't had a chance to check on v3.0 (I'm currently travelling and
> penning this from an airplane), but on v3.1-rc3, it works for me under
> KVM. I fire up kvm-qemu this way:
>
> $QEMU -enable-kvm -boot order=c $NET \
> -drive file=$ROOT_QCOW2,if=virtio$SNAPSHOT \
> -drive file=$VDB,cache=none,if=virtio \
> -drive file=$VDC,cache=none,if=virtio \
> -drive file=$VDD,cache=none,if=virtio \
> -nographic -smp $NR_CPU -m $MEM \
> --kernel $KERNEL \
> --append "root=/dev/vda console=ttyS0,115200 rootflags=data=writeback" |\
> tee $LOGFILE
>
> with this in /proc/cmdline:
>
> candygram:~# cat /proc/cmdline
> root=/dev/vda console=ttyS0,115200 rootflags=data=writeback maint
>
> ... and this is what I have in /proc/mounts:
>
> candygram:~# head -2 /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/root / ext4 rw,noatime,user_xattr,acl,barrier=1,data=writeback 0 0
>
> ... and what I have in /etc/fstab:
>
> UUID=ce4d6b98-2aa9-42d4-a127-995a795a0b02 / ext4 noatime,data=writeback 0 1
>
> The kvm image I'm using is using Debian unstable image generated using
> debootstrap, and uses no modules or initrd's --- which makes it easier
> for me to boot since $KERNEL is set to:
>
> /tyt/linux/ext4/arch/x86/boot/bzImage
>
> This allows me to fire up test kernel right from my build tree,
> without needing to set up any kind of initrd nonsense. :-)
>
> - Ted
^ permalink raw reply
* Re: [PATCH 1/6] ext4: cleanup ext4_ext_grow_indepth code
From: Ted Ts'o @ 2011-10-22 5:27 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: linux-ext4, achender
In-Reply-To: <1319144939-28801-2-git-send-email-dmonakhov@openvz.org>
On Fri, Oct 21, 2011 at 01:08:54AM +0400, Dmitry Monakhov wrote:
> Currently code make an impression what grow procedure is very complicated
> and some mythical paths, blocks are involved. But in fact grow in depth
> it relatively simple procedure:
> 1) Just create new meta block and copy roots content to it
> 2) Convert root from extent to index if old depth == 0
> 3) update root block pointer
>
Applied, thanks.
BTW:
> - Do not pass path parameter to new_meta_block() in order to
> provoke allocation from inode's group because top-level block
> should site closer to it's inode, but not to leaf data block.
This happens anyway, due to logic in mballoc; as a result the path
parameter in ext4_ext_new_meta_block() is really pointless, and should
be dropped.
- Ted
^ permalink raw reply
* Re: Bug In ext4 in kernels > 2.6.39 - Not mounting with arguments/options I specify in fstab on root remount
From: Ted Ts'o @ 2011-10-22 5:00 UTC (permalink / raw)
To: Matt Parnell; +Cc: Eric Sandeen, linux-ext4
In-Reply-To: <4EA0E72D.8020305@gmail.com>
On Thu, Oct 20, 2011 at 10:29:49PM -0500, Matt Parnell wrote:
> The output of /proc/cmdline on 3.0.7:
>
> BOOT_IMAGE=/boot/vmlinuz26-zen root=/dev/sdb1 ro rootfstype=ext4
> rootflags=data=writeback noatime nodiratime barrier=0 discard
> noinitrd
>
>
> On 10/09/2011 06:44 PM, Ted Ts'o wrote:
> >On Sun, Oct 09, 2011 at 05:10:54PM -0500, Matt Parnell wrote:
> >>/proc/mounts (as you can see it's not being remounted rw for some
> >>reason - /dev/sdc1 is the flash drive I used to pipe this info onto):
> >>
> >>rootfs / rootfs rw 0 0
> >>/dev/root / ext4 ro,relatime,barrier=1 0 0
I haven't had a chance to check on v3.0 (I'm currently travelling and
penning this from an airplane), but on v3.1-rc3, it works for me under
KVM. I fire up kvm-qemu this way:
$QEMU -enable-kvm -boot order=c $NET \
-drive file=$ROOT_QCOW2,if=virtio$SNAPSHOT \
-drive file=$VDB,cache=none,if=virtio \
-drive file=$VDC,cache=none,if=virtio \
-drive file=$VDD,cache=none,if=virtio \
-nographic -smp $NR_CPU -m $MEM \
--kernel $KERNEL \
--append "root=/dev/vda console=ttyS0,115200 rootflags=data=writeback" |\
tee $LOGFILE
with this in /proc/cmdline:
candygram:~# cat /proc/cmdline
root=/dev/vda console=ttyS0,115200 rootflags=data=writeback maint
... and this is what I have in /proc/mounts:
candygram:~# head -2 /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext4 rw,noatime,user_xattr,acl,barrier=1,data=writeback 0 0
... and what I have in /etc/fstab:
UUID=ce4d6b98-2aa9-42d4-a127-995a795a0b02 / ext4 noatime,data=writeback 0 1
The kvm image I'm using is using Debian unstable image generated using
debootstrap, and uses no modules or initrd's --- which makes it easier
for me to boot since $KERNEL is set to:
/tyt/linux/ext4/arch/x86/boot/bzImage
This allows me to fire up test kernel right from my build tree,
without needing to set up any kind of initrd nonsense. :-)
- Ted
^ permalink raw reply
* Re: How do I clear the append-only flag on symlinks?
From: Ted Ts'o @ 2011-10-22 5:16 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: linux-ext4
In-Reply-To: <CAObL_7FLTio3+X3iQ3sdHw156OvmjT92_AD0vKTSagNTkaF9fQ@mail.gmail.com>
On Fri, Oct 21, 2011 at 11:07:51AM -0700, Andrew Lutomirski wrote:
> By means that are best not admitted to, I managed to mark a large
> chunk of my filesystem append-only, including symlinks. I cleared the
> flag from all the normal files and directories, but chattr and lsattr
> don't want to operate on symlinks.
Yes. So how did you set a whole chunk of your file system
append-only?
> Any ideas on how to clear the append-only flags? debug2fs is a little
> scary, and hacking e2fsprogs to allow operation on symlinks seems to
> affect symlink targets and not the symlinks themselves.
I'd probably hack it into e2fsck, and let it offer to clear the
append-only flag on things that aren't regular files, on the theory
that they should have never been allowed to be set to begin with.
- Ted
^ permalink raw reply
* Re: [PATCH 0/7] writeback: avoid touching dirtied_when on blocked inodes
From: Wu Fengguang @ 2011-10-22 7:46 UTC (permalink / raw)
To: Jan Kara
Cc: linux-fsdevel@vger.kernel.org, Dave Chinner, Christoph Hellwig,
Andrew Morton, LKML
In-Reply-To: <20111022053851.GA23033@localhost>
On Sat, Oct 22, 2011 at 01:38:51PM +0800, Wu Fengguang wrote:
> On Sat, Oct 22, 2011 at 11:11:35AM +0800, Wu Fengguang wrote:
> > > > btw, with the I_SYNC case converted, it's actually no longer necessary
> > > > to keep a standalone b_more_io_wait. It should still be better to keep
> > > > the list and the above error check for catching possible errors and
> > > > the flexibility of adding policies like "don't retry possible blocked
> > > > inodes in N seconds as long as there are other inodes to work with".
> > > >
> > > > The below diff only intends to show the _possibility_ to remove
> > > > b_more_io_wait:
> > > Good observation. So should we introduce b_more_io_wait in the end? We
> > > could always introduce it when the need for some more complicated policy
> > > comes...
> > >
> >
> > I have no problem removing it if you liked it more. Anyway, let me
> > test the idea out first (just kicked off the tests).
>
> When removing b_more_io_wait, performance is slightly dropped
> comparing to the full more_io_wait patchset.
>
> 3.1.0-rc9-ioless-full-more_io_wait-next-20111014+ 3.1.0-rc9-ioless-full-more_io_wait-x-next-20111014+
> ------------------------ ------------------------
> 45.30 +6.3% 48.14 thresh=1G/ext3-1dd-4k-8p-4096M-1024M:10-X
> 48.23 -2.0% 47.27 thresh=1G/ext4-100dd-4k-8p-4096M-1024M:10-X
> 54.21 -2.6% 52.80 thresh=1G/ext4-10dd-4k-8p-4096M-1024M:10-X
> 56.07 -0.3% 55.91 thresh=1G/ext4-1dd-4k-8p-4096M-1024M:10-X
> 45.12 -5.8% 42.49 thresh=1G/xfs-100dd-4k-8p-4096M-1024M:10-X
> 53.94 -1.2% 53.27 thresh=1G/xfs-10dd-4k-8p-4096M-1024M:10-X
> 55.66 -0.1% 55.63 thresh=1G/xfs-1dd-4k-8p-4096M-1024M:10-X
> 358.53 -0.8% 355.51 TOTAL write_bw
>
> I'll try to reduce the changes and retest.
Unfortunately, the reduced patches 1-4 + I_SYNC change + remove
requeue_more_io_wait combination still performances noticeably worse:
3.1.0-rc9-ioless-full-next-20111014+ 3.1.0-rc9-ioless-full-more_io_wait-x2-next-20111014+
------------------------ ------------------------
49.84 -7.9% 45.91 thresh=1G/ext4-100dd-4k-8p-4096M-1024M:10-X
56.03 -7.2% 52.01 thresh=1G/ext4-10dd-4k-8p-4096M-1024M:10-X
57.42 -1.7% 56.45 thresh=1G/ext4-1dd-4k-8p-4096M-1024M:10-X
45.74 -2.8% 44.48 thresh=1G/xfs-100dd-4k-8p-4096M-1024M:10-X
54.19 -4.8% 51.57 thresh=1G/xfs-10dd-4k-8p-4096M-1024M:10-X
55.93 -2.2% 54.70 thresh=1G/xfs-1dd-4k-8p-4096M-1024M:10-X
319.14 -4.4% 305.12 TOTAL write_bw
Thanks,
Fengguang
^ permalink raw reply
* Re: [PATCH] Makefile: Remove duplicate description of "make RECORDMCOUNT_WARN=1"
From: Jongman Heo @ 2011-10-22 7:43 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <CAHFnbA=sz+_8rESX212aRphen5YCC6ikoX2riprCZBh4wp1O9Q@mail.gmail.com>
2011/10/22 Jongman Heo <jongman.heo@gmail.com>:
> Remove duplicate "make RECORDMCOUNT_WARN=1" description from "make help" output
>
> Signed-off-by: Jongman Heo <jongman.heo@gmail.com>
> ---
> Makefile | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 2652089..86437a3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1290,7 +1290,6 @@ help:
> @echo ' make O=dir [targets] Locate all output files in "dir",
> including .config'
> @echo ' make C=1 [targets] Check all c source with $$CHECK
> (sparse by default)'
> @echo ' make C=2 [targets] Force check of all c source with $$CHECK'
> - @echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored
> mcount sections'
> @echo ' make W=n [targets] Enable extra gcc checks, n=1,2,3 where'
> @echo ' 1: warnings which may be relevant and do not occur too often'
> @echo ' 2: warnings which occur quite often but may still be relevant'
> --
> 1.7.6.4
>
Sorry for the unwanted line wrapping, I couldn't find a way to disable
automatic line wrapping of gmail.
But this is simple, one-liner patch, hope it's fine.
Regards,
jongman.
^ permalink raw reply
* [BUG] bonding : LOCKDEP warning
From: Eric Dumazet @ 2011-10-22 7:36 UTC (permalink / raw)
To: netdev
On latest net-next I got following splat
[ 5.749651] bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 5.749655] bonding: MII link monitoring set to 100 ms
[ 5.749676] BUG: key f49a831c not in .data!
[ 5.749677] ------------[ cut here ]------------
[ 5.749752] WARNING: at kernel/lockdep.c:2897 lockdep_init_map+0x1c3/0x460()
[ 5.749809] Hardware name: ProLiant BL460c G1
[ 5.749862] Modules linked in: bonding(+)
[ 5.749978] Pid: 3177, comm: modprobe Not tainted 3.1.0-rc9-02177-gf2d1a4e-dirty #1157
[ 5.750066] Call Trace:
[ 5.750120] [<c1352c2f>] ? printk+0x18/0x21
[ 5.750176] [<c103112d>] warn_slowpath_common+0x6d/0xa0
[ 5.750231] [<c1060133>] ? lockdep_init_map+0x1c3/0x460
[ 5.750287] [<c1060133>] ? lockdep_init_map+0x1c3/0x460
[ 5.750342] [<c103117d>] warn_slowpath_null+0x1d/0x20
[ 5.750398] [<c1060133>] lockdep_init_map+0x1c3/0x460
[ 5.750453] [<c1355ddd>] ? _raw_spin_unlock+0x1d/0x20
[ 5.750510] [<c11255c8>] ? sysfs_new_dirent+0x68/0x110
[ 5.750565] [<c1124d4b>] sysfs_add_file_mode+0x8b/0xe0
[ 5.750621] [<c1124db3>] sysfs_add_file+0x13/0x20
[ 5.750675] [<c1124e7c>] sysfs_create_file+0x1c/0x20
[ 5.750737] [<c1208f09>] class_create_file+0x19/0x20
[ 5.750794] [<c12c186f>] netdev_class_create_file+0xf/0x20
[ 5.750853] [<f85deaf4>] bond_create_sysfs+0x44/0x90 [bonding]
[ 5.750911] [<f8410947>] ? bond_create_proc_dir+0x1e/0x3e [bonding]
[ 5.750970] [<f841007e>] bond_net_init+0x7e/0x87 [bonding]
[ 5.751026] [<f8410000>] ? 0xf840ffff
[ 5.751080] [<c12abc7a>] ops_init.clone.4+0xba/0x100
[ 5.751135] [<c12abdb2>] ? register_pernet_subsys+0x12/0x30
[ 5.751191] [<c12abd03>] register_pernet_operations.clone.3+0x43/0x80
[ 5.751249] [<c12abdb9>] register_pernet_subsys+0x19/0x30
[ 5.751306] [<f84108b9>] bonding_init+0x832/0x8a2 [bonding]
[ 5.751363] [<c10011f0>] do_one_initcall+0x30/0x160
[ 5.751420] [<f8410087>] ? bond_net_init+0x87/0x87 [bonding]
[ 5.751477] [<c106d5cf>] sys_init_module+0xef/0x1890
[ 5.751533] [<c1356490>] sysenter_do_call+0x12/0x36
[ 5.751588] ---[ end trace 89f492d83a7f5006 ]---
^ permalink raw reply
* Re: [PATCH 1/2] nfs: writeback pages wait queue
From: Wu Fengguang @ 2011-10-22 7:34 UTC (permalink / raw)
To: Trond Myklebust, linux-nfs
Cc: Peter Zijlstra, linux-fsdevel@vger.kernel.org, Andrew Morton,
Jan Kara, Christoph Hellwig, Dave Chinner, Greg Thelen,
Minchan Kim, Vivek Goyal, Andrea Righi, linux-mm, LKML
In-Reply-To: <20111020160530.GC7054@localhost>
[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]
Hi,
Aside from the big improvements in the 1G,100M,10M cases, the
thresh=1M cases show big regressions. But there is a good reason.
> 3.1.0-rc8-vanilla+ 3.1.0-rc8-nfs-wq4+
> ------------------------ ------------------------
> 21.85 +97.9% 43.23 NFS-thresh=100M/nfs-10dd-4k-32p-32768M-100M:10-X
> 51.38 +42.6% 73.26 NFS-thresh=100M/nfs-1dd-4k-32p-32768M-100M:10-X
> 28.81 +145.3% 70.68 NFS-thresh=100M/nfs-2dd-4k-32p-32768M-100M:10-X
> 13.74 +57.1% 21.59 NFS-thresh=10M/nfs-10dd-4k-32p-32768M-10M:10-X
> 29.11 -0.3% 29.02 NFS-thresh=10M/nfs-1dd-4k-32p-32768M-10M:10-X
> 16.68 +90.5% 31.78 NFS-thresh=10M/nfs-2dd-4k-32p-32768M-10M:10-X
> 48.88 +41.2% 69.01 NFS-thresh=1G/nfs-10dd-4k-32p-32768M-1024M:10-X
> 57.85 +32.7% 76.74 NFS-thresh=1G/nfs-1dd-4k-32p-32768M-1024M:10-X
> 47.13 +63.1% 76.87 NFS-thresh=1G/nfs-2dd-4k-32p-32768M-1024M:10-X
> 9.82 -33.0% 6.58 NFS-thresh=1M/nfs-10dd-4k-32p-32768M-1M:10-X
> 13.72 -18.1% 11.24 NFS-thresh=1M/nfs-1dd-4k-32p-32768M-1M:10-X
> 15.68 -65.0% 5.48 NFS-thresh=1M/nfs-2dd-4k-32p-32768M-1M:10-X
> 354.65 +45.4% 515.48 TOTAL write_bw
The regressions in the thresh=1M cases are reasonably caused by the
much reduced dirty/writeback/unstable pages.
The attached graphs for the NFS-thresh=1M/nfs-10dd cases show the
differences. The vanilla kernel (first graph) is much more permissive
to allow dirty pages to exceed the global dirty limit, while the
IO-less one applies the global dirty limit much more rigidly.
Given the 18MB vs. 3MB max dirty+writeback+unstable pages, it's not
surprising to see the better performance in the vanilla kernel. And
it does not mean anything inherently wrong in the IO-less logic.
Thanks,
Fengguang
[-- Attachment #2: global_dirty_state.png --]
[-- Type: image/png, Size: 271327 bytes --]
[-- Attachment #3: global_dirty_state.png --]
[-- Type: image/png, Size: 189314 bytes --]
^ permalink raw reply
* [PATCH] Makefile: Remove duplicate description of "make RECORDMCOUNT_WARN=1"
From: Jongman Heo @ 2011-10-22 7:32 UTC (permalink / raw)
To: linux-kernel
Remove duplicate "make RECORDMCOUNT_WARN=1" description from "make help" output
Signed-off-by: Jongman Heo <jongman.heo@gmail.com>
---
Makefile | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 2652089..86437a3 100644
--- a/Makefile
+++ b/Makefile
@@ -1290,7 +1290,6 @@ help:
@echo ' make O=dir [targets] Locate all output files in "dir",
including .config'
@echo ' make C=1 [targets] Check all c source with $$CHECK
(sparse by default)'
@echo ' make C=2 [targets] Force check of all c source with $$CHECK'
- @echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored
mcount sections'
@echo ' make W=n [targets] Enable extra gcc checks, n=1,2,3 where'
@echo ' 1: warnings which may be relevant and do not occur too often'
@echo ' 2: warnings which occur quite often but may still be relevant'
--
1.7.6.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.