* Re: [Qemu-devel] [PATCH v3 01/13] remove unused function
From: Anthony Liguori @ 2011-10-31 18:10 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <1319214405-20388-2-git-send-email-pbonzini@redhat.com>
Are you planning on spinning a v4 with TeLeMan's suggestions by tomorrow?
Regards,
Anthony Liguori
On 10/21/2011 11:26 AM, Paolo Bonzini wrote:
> Reviewed-by: Anthony Liguori<aliguori@us.ibm.com>
> Signed-off-by: Paolo Bonzini<pbonzini@redhat.com>
> ---
> hw/mac_dbdma.c | 5 -----
> hw/mac_dbdma.h | 1 -
> 2 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/hw/mac_dbdma.c b/hw/mac_dbdma.c
> index 5affdd1..1791ec1 100644
> --- a/hw/mac_dbdma.c
> +++ b/hw/mac_dbdma.c
> @@ -661,11 +661,6 @@ void DBDMA_register_channel(void *dbdma, int nchan, qemu_irq irq,
> ch->io.channel = ch;
> }
>
> -void DBDMA_schedule(void)
> -{
> - qemu_notify_event();
> -}
> -
> static void
> dbdma_control_write(DBDMA_channel *ch)
> {
> diff --git a/hw/mac_dbdma.h b/hw/mac_dbdma.h
> index 933e17c..6d1abe6 100644
> --- a/hw/mac_dbdma.h
> +++ b/hw/mac_dbdma.h
> @@ -41,5 +41,4 @@ struct DBDMA_io {
> void DBDMA_register_channel(void *dbdma, int nchan, qemu_irq irq,
> DBDMA_rw rw, DBDMA_flush flush,
> void *opaque);
> -void DBDMA_schedule(void);
> void* DBDMA_init (MemoryRegion **dbdma_mem);
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 0/3] TLS abstraction layer for thread-local cpu_single_env on Linux
From: Anthony Liguori @ 2011-10-31 18:08 UTC (permalink / raw)
To: Peter Maydell
Cc: Dr. David Alan Gilbert, patches, Jan Kiszka, qemu-devel,
Paolo Bonzini, Andreas Färber
In-Reply-To: <CAFEAcA_LS1zC8_o_bQ+X4sz8+6TUPvUus0D9-7y1ARw=ws9PyQ@mail.gmail.com>
On 10/31/2011 08:40 AM, Peter Maydell wrote:
> An early ping since I have no idea who counts as the submaintainer
> for this patchset and it definitely needs to go in for 1.0...
I'm in the process of testing them and will apply provided nothing breaks.
Regards,
Anthony Liguori
>
> thanks
> -- PMM
>
> On 28 October 2011 10:52, Peter Maydell<peter.maydell@linaro.org> wrote:
>> These patches add enough of the TLS abstraction layer to allow us
>> to make cpu_single_env thread-local on Linux systems. This fixes
>> the regression described in bug 823902 for the 1.0 release; we
>> can add the Win32 and POSIX implementations later.
>>
>> I haven't included Paolo's "Prepare Windows port for thread-local
>> cpu_single_env" patch -- it would be safe to do so but it isn't
>> necessary until we actually implement TLS for Win32.
>>
>> Changes v1->v2:
>> * fix Paolo's email address
>> * split the darwin-user change out into a separate patch
>> * drop the 'tls_' prefix from the cpu_single_env tls var name
>> Changes v2->v3:
>> * minor rearrangement of copyright notice in comment
>> * added a missing Signed-off-by
>> * fixed the name of the multiple-include-guard #define
>>
>> Paolo Bonzini (2):
>> darwin-user/main.c: Drop unused cpu_single_env definition
>> Make cpu_single_env thread-local
>>
>> Peter Maydell (1):
>> qemu-tls.h: Add abstraction layer for TLS variables
>>
>> cpu-all.h | 4 +++-
>> darwin-user/main.c | 2 --
>> exec.c | 2 +-
>> qemu-tls.h | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 56 insertions(+), 4 deletions(-)
>> create mode 100644 qemu-tls.h
>
>
^ permalink raw reply
* [U-Boot] [PATCH v7 1/4] tegra2: Move MMC clock initialization into MMC driver
From: Simon Glass @ 2011-10-31 18:08 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320079897-29473-1-git-send-email-swarren@nvidia.com>
Hi Stephen,
On Mon, Oct 31, 2011 at 9:51 AM, Stephen Warren <swarren@nvidia.com> wrote:
> This centralizes knowledge of MMC clocking into the MMC driver. This also
> removes clock setup from the board files, which will simplify later changes
> that modify the Harmony board to support the correct set of MMC controllers.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> Cc: Andy Fleming <afleming@gmail.com>
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>
I retested this new patch series with the latest master (mmc part,
ext2ls and ext2load) and it is fine.
Regards,
Simon
> ---
> ?board/nvidia/common/board.c | ? 13 +------------
> ?drivers/mmc/tegra2_mmc.c ? ?| ? 12 +++++++++---
> ?2 files changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
> index d13537d..370a259 100644
> --- a/board/nvidia/common/board.c
> +++ b/board/nvidia/common/board.c
> @@ -102,16 +102,6 @@ static void pin_mux_uart(void)
>
> ?#ifdef CONFIG_TEGRA2_MMC
> ?/*
> - * Routine: clock_init_mmc
> - * Description: init the PLL and clocks for the SDMMC controllers
> - */
> -static void clock_init_mmc(void)
> -{
> - ? ? ? clock_start_periph_pll(PERIPH_ID_SDMMC4, CLOCK_ID_PERIPH, 20000000);
> - ? ? ? clock_start_periph_pll(PERIPH_ID_SDMMC3, CLOCK_ID_PERIPH, 20000000);
> -}
> -
> -/*
> ?* Routine: pin_mux_mmc
> ?* Description: setup the pin muxes/tristate values for the SDMMC(s)
> ?*/
> @@ -157,8 +147,7 @@ int board_init(void)
> ?int board_mmc_init(bd_t *bd)
> ?{
> ? ? ? ?debug("board_mmc_init called\n");
> - ? ? ? /* Enable clocks, muxes, etc. for SDMMC controllers */
> - ? ? ? clock_init_mmc();
> + ? ? ? /* Enable muxes, etc. for SDMMC controllers */
> ? ? ? ?pin_mux_mmc();
> ? ? ? ?gpio_config_mmc();
>
> diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
> index 9e741f2..78b1190 100644
> --- a/drivers/mmc/tegra2_mmc.c
> +++ b/drivers/mmc/tegra2_mmc.c
> @@ -435,14 +435,22 @@ static int mmc_core_init(struct mmc *mmc)
>
> ?static int tegra2_mmc_initialize(int dev_index, int bus_width)
> ?{
> + ? ? ? struct mmc_host *host;
> ? ? ? ?struct mmc *mmc;
>
> ? ? ? ?debug(" mmc_initialize called\n");
>
> + ? ? ? host = &mmc_host[dev_index];
> +
> + ? ? ? host->clock = 0;
> + ? ? ? tegra2_get_setup(host, dev_index);
> +
> + ? ? ? clock_start_periph_pll(host->mmc_id, CLOCK_ID_PERIPH, 20000000);
> +
> ? ? ? ?mmc = &mmc_dev[dev_index];
>
> ? ? ? ?sprintf(mmc->name, "Tegra2 SD/MMC");
> - ? ? ? mmc->priv = &mmc_host[dev_index];
> + ? ? ? mmc->priv = host;
> ? ? ? ?mmc->send_cmd = mmc_send_cmd;
> ? ? ? ?mmc->set_ios = mmc_set_ios;
> ? ? ? ?mmc->init = mmc_core_init;
> @@ -465,8 +473,6 @@ static int tegra2_mmc_initialize(int dev_index, int bus_width)
> ? ? ? ?mmc->f_min = 375000;
> ? ? ? ?mmc->f_max = 48000000;
>
> - ? ? ? mmc_host[dev_index].clock = 0;
> - ? ? ? tegra2_get_setup(&mmc_host[dev_index], dev_index);
> ? ? ? ?mmc_register(mmc);
>
> ? ? ? ?return 0;
> --
> 1.7.0.4
>
>
^ permalink raw reply
* Re: Patches for BTRFS (mail-server slow down in 3.0 and more)
From: Alexandre Oliva @ 2011-10-31 18:08 UTC (permalink / raw)
To: Chris Mason; +Cc: Marcel Lohmann, linux-btrfs
In-Reply-To: <20111031143027.GD19328@twin.jikos.cz>
On Oct 31, 2011, David Sterba <dave@jikos.cz> wrote:
> On Mon, Oct 31, 2011 at 02:19:18AM -0200, Alexandre Oliva wrote:
>> On Oct 29, 2011, Chris Mason <chris.mason@oracle.com> wrote:
>>
>> > The last one isn't a bad idea, but please do make a real mount option
>> > for it ;)
>>
>> Like this?
> @@ -195,6 +195,7 @@ static match_table_t tokens = {
> {Opt_subvolrootid, "subvolrootid=%d"},
> {Opt_defrag, "autodefrag"},
> {Opt_inode_cache, "inode_cache"},
> + {Opt_nocluster, "nocluster"},
> {Opt_err, NULL},
> How about 'no_alloc_cluster' ?
I considered that, too, but choosing the option name was the most
difficult part of the patch :-) I ended up going for the shorter name,
just to get the conversation started ;-) I don't feel strongly about it.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
^ permalink raw reply
* Re: [PATCH 05/27] Initconst section fixes for M68K
From: Geert Uytterhoeven @ 2011-10-31 18:05 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel, Andi Kleen
In-Reply-To: <1316117394-21666-6-git-send-email-andi@firstfloor.org>
On Thu, Sep 15, 2011 at 22:09, Andi Kleen <andi@firstfloor.org> wrote:
> From: Andi Kleen <ak@linux.intel.com>
>
> Cc: geert@linux-m68k.org
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> arch/m68k/emu/nfeth.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/m68k/emu/nfeth.c b/arch/m68k/emu/nfeth.c
> index c5748bb..a985a7e 100644
> --- a/arch/m68k/emu/nfeth.c
> +++ b/arch/m68k/emu/nfeth.c
> @@ -39,7 +39,7 @@ enum {
> #define MAX_UNIT 8
>
> /* These identify the driver base version and may not be removed. */
> -static const char version[] __devinitdata =
> +static const char version[] __devinitconst =
> KERN_INFO KBUILD_MODNAME ".c:v" DRV_VERSION " " DRV_RELDATE
> " S.Opichal, M.Jurik, P.Stehlik\n"
> KERN_INFO " http://aranym.org/\n";
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: how to run ceph on top of other local file system
From: Tommi Virtanen @ 2011-10-31 18:05 UTC (permalink / raw)
To: sheng qiu; +Cc: Sage Weil, ceph-devel
In-Reply-To: <CAB7xdinQ8uVDxX5R5bGF1mvGG_RLANNQ8A9Lweu4hDtGjnQ_HA@mail.gmail.com>
On Fri, Oct 28, 2011 at 12:12, sheng qiu <herbert1984106@gmail.com> wrote:
> thanks for your help. i have built up the system and run postmark and
> iozone to get some performance data. my system contains two machine,
> one is set as monitor, mds and osd. another is set as mds and osd.
> each osd is a SSD with ext3.
At this point, I would advise against running multiple active MDSes.
That configuration is not tested well enough, and might be the source
of all your troubles.
Unfortunately, we do not currently have benchmarks we could share. Our
QA work is still currently focused on correctness under heavy stress,
not performance.
^ permalink raw reply
* [U-Boot] [PATCH 5/6] PXA: Cleanup serial_pxa
From: Marek Vasut @ 2011-10-31 18:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1314495737-29436-5-git-send-email-marek.vasut@gmail.com>
> * Cleanup register definitions by introducing new regs-uart.h, compliant
> with rest of U-Boot.
> * Remove old register definitions from pxa-regs.h
> * Convert serial_pxa to new regs-uart.h
> * Cleanup serial_pxa
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Hi Albert,
did you pick this one up? Maybe we can pick it up for .12 release?
Cheers
^ permalink raw reply
* Problem with dump-core after restoring VM
From: Dawid @ 2011-10-31 18:02 UTC (permalink / raw)
To: xen-devel
Hi,
Sorry to bother you, but I have some problems with dumping core of HVM
domain after previously restoring it from a given save point. After
starting HVM domain from a scratch (i.e. xm/xl create ..) there is no
problem with dumping core. But when I decide to save VM and then restore
it, dump-core fails afterwards.
dom0: Debian Squeeze
hvm domain: Windows Xp (tried both 32bit and 64bit version)
Xen hypervisor: tried on machine with Xen 4.1 (dom0 kernel 3.0.0) and
also Xen 4.0 (dom0 kernel 2.6.32)
Using xm I got error (it's xmlrpclib.Fault exception in _run_cmd() at
xm/main.py):
Fault 2: "Failed to dump core: (1, 'Internal error', 'Failed to write
buffer (14 = Bad address)')"
Using new xl toolstack I got similar error:
xc: error: Failed to write buffer (14 = Bad address): Internal error
libxl: error: libxl.c:479:libxl_domain_core_dump core dumping domain 14
to ./dump.2: Bad address
core dump failed (rc=-3)
Doing `xm save -c` without stopping VM doesn't cause problem with
core-dump (well, it would be strange if it does), so it seems problem
exist only after restoring VM.
Regards,
David
^ permalink raw reply
* infiniband.git back to kernel.org
From: Roland Dreier @ 2011-10-31 18:01 UTC (permalink / raw)
To: linux-kernel, linux-rdma, Stephen Rothwell
Hi everyone,
I've reactivated my kernel.org tree, and my tree is once again at
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
Stephen, you can return to using the for-next branch of that tree
as convenient for you.
For the moment I am keeping my github tree up-to-date as well,
although at some point I expect to get rid of that tree.
Thanks,
Roland
^ permalink raw reply
* infiniband.git back to kernel.org
From: Roland Dreier @ 2011-10-31 18:01 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Stephen Rothwell
Hi everyone,
I've reactivated my kernel.org tree, and my tree is once again at
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
Stephen, you can return to using the for-next branch of that tree
as convenient for you.
For the moment I am keeping my github tree up-to-date as well,
although at some point I expect to get rid of that tree.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] hw/9pfs: use g_vasprintf() instead of rolling our own
From: Aneesh Kumar K.V @ 2011-10-31 17:58 UTC (permalink / raw)
To: Stefan Hajnoczi, qemu-devel; +Cc: Markus Armbruster
In-Reply-To: <1320061773-10634-1-git-send-email-stefanha@linux.vnet.ibm.com>
On Mon, 31 Oct 2011 11:49:33 +0000, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> wrote:
> Markus Armbruster <armbru@redhat.com> sent fixes for va_list vararg
> issues in v9fs_string_alloc_printf(). It turns out the function
> duplicates g_vasprintf() and can therefore be eliminated entirely.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> hw/9pfs/virtio-9p.c | 103 ++-------------------------------------------------
> 1 files changed, 4 insertions(+), 99 deletions(-)
>
> diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> index 8b6813f..253919b 100644
> --- a/hw/9pfs/virtio-9p.c
> +++ b/hw/9pfs/virtio-9p.c
> @@ -11,6 +11,9 @@
> *
> */
>
> +#include <glib.h>
> +#include <glib/gprintf.h>
> +
> #include "hw/virtio.h"
> #include "hw/pc.h"
> #include "qemu_socket.h"
> @@ -161,114 +164,16 @@ void v9fs_string_null(V9fsString *str)
> v9fs_string_free(str);
> }
>
> -static int number_to_string(void *arg, char type)
> -{
> - unsigned int ret = 0;
> -
> - switch (type) {
> - case 'u': {
> - unsigned int num = *(unsigned int *)arg;
> -
> - do {
> - ret++;
> - num = num/10;
> - } while (num);
> - break;
> - }
> - case 'U': {
> - unsigned long num = *(unsigned long *)arg;
> - do {
> - ret++;
> - num = num/10;
> - } while (num);
> - break;
> - }
> - default:
> - printf("Number_to_string: Unknown number format\n");
> - return -1;
> - }
> -
> - return ret;
> -}
> -
> -static int GCC_FMT_ATTR(2, 0)
> -v9fs_string_alloc_printf(char **strp, const char *fmt, va_list ap)
> -{
> - va_list ap2;
> - char *iter = (char *)fmt;
> - int len = 0;
> - int nr_args = 0;
> - char *arg_char_ptr;
> - unsigned int arg_uint;
> - unsigned long arg_ulong;
> -
> - /* Find the number of %'s that denotes an argument */
> - for (iter = strstr(iter, "%"); iter; iter = strstr(iter, "%")) {
> - nr_args++;
> - iter++;
> - }
> -
> - len = strlen(fmt) - 2*nr_args;
> -
> - if (!nr_args) {
> - goto alloc_print;
> - }
> -
> - va_copy(ap2, ap);
> -
> - iter = (char *)fmt;
> -
> - /* Now parse the format string */
> - for (iter = strstr(iter, "%"); iter; iter = strstr(iter, "%")) {
> - iter++;
> - switch (*iter) {
> - case 'u':
> - arg_uint = va_arg(ap2, unsigned int);
> - len += number_to_string((void *)&arg_uint, 'u');
> - break;
> - case 'l':
> - if (*++iter == 'u') {
> - arg_ulong = va_arg(ap2, unsigned long);
> - len += number_to_string((void *)&arg_ulong, 'U');
> - } else {
> - return -1;
> - }
> - break;
> - case 's':
> - arg_char_ptr = va_arg(ap2, char *);
> - len += strlen(arg_char_ptr);
> - break;
> - case 'c':
> - len += 1;
> - break;
> - default:
> - fprintf(stderr,
> - "v9fs_string_alloc_printf:Incorrect format %c", *iter);
> - return -1;
> - }
> - iter++;
> - }
> -
> -alloc_print:
> - *strp = g_malloc((len + 1) * sizeof(**strp));
> -
> - return vsprintf(*strp, fmt, ap);
> -}
> -
> void GCC_FMT_ATTR(2, 3)
> v9fs_string_sprintf(V9fsString *str, const char *fmt, ...)
> {
> va_list ap;
> - int err;
>
> v9fs_string_free(str);
>
> va_start(ap, fmt);
> - err = v9fs_string_alloc_printf(&str->data, fmt, ap);
> - BUG_ON(err == -1);
> + str->size = g_vasprintf(&str->data, fmt, ap);
> va_end(ap);
> -
> - str->size = err;
> }
>
> void v9fs_string_copy(V9fsString *lhs, V9fsString *rhs)
> --
> 1.7.7
>
^ permalink raw reply
* Re: [PATCH] IB/qib: Fix kernel panic on QME7342 boards
From: Roland Dreier @ 2011-10-31 17:59 UTC (permalink / raw)
To: Mike Marciniszyn; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111025164207.31124.13380.stgit-hIFRcJ1SNwcXGO8/Qfapyjg/wwJxntczYPYVAmT7z5s@public.gmane.org>
On Tue, Oct 25, 2011 at 9:42 AM, Mike Marciniszyn
<mike.marciniszyn-h88ZbnxC6KDQT0dZR+AlfA@public.gmane.org> wrote:
> introduced by 62066fc8df4632c772d723813ce7af456d62ddf7.
Thanks, rolled this into that commit since it wasn't upstream yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git tree URL for IEEE 1394 (FireWire) kernel subsystem
From: Stefan Richter @ 2011-10-31 17:57 UTC (permalink / raw)
To: Stephen Rothwell, linux-next; +Cc: linux1394-devel, linux-kernel
In-Reply-To: <20110918215144.f33db78e54224626c6ee408e@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
Stephen,
please switch the ieee1394/for-next URL once more, now to
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git for-next
which is meant to be permanent. (-2.6 suffix of the former name
dropped). Current content is identical with my pull request to
Linus today.
Thanks,
--
Stefan Richter
-=====-==-== =-=- =====
http://arcgraph.de/sr/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] blame.c: Properly initialize strbuf after calling, textconv_object()
From: Sebastian Schuberth @ 2011-10-31 17:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit
In-Reply-To: <7vd3dht4ms.fsf@alter.siamese.dyndns.org>
On Fri, Oct 28, 2011 at 19:20, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> Thanks; do you have no addition to the test suite to demonstrate the
>>>>> breakage?
>>>>
>>>> Not yet. I'll try to come up with something.
>>>
>>> Let's do this.
>>
>> Thanks, but that does not seem to work for me. The test breaks both
>> without and with my patch. I'll look into it.
>
> Thanks. I suspect the difference is because you are on a crlf-native
> platform while I am not...
I've got a test now. However, that test revealed some more related
issues. I'll come up with a v2 of the patch this week.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Benny Halevy @ 2011-10-31 17:57 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Peng Tao, linux-nfs, Peng Tao, nfsv4 list
In-Reply-To: <1320082964.4714.23.camel@lade.trondhjem.org>
On 2011-10-31 19:42, Trond Myklebust wrote:
> On Mon, 2011-10-31 at 19:08 +0200, Benny Halevy wrote:
>> On 2011-10-31 18:45, Trond Myklebust wrote:
>>> On Tue, 2011-11-01 at 00:38 +0800, Peng Tao wrote:
>>>> On Mon, Oct 31, 2011 at 11:49 PM, Trond Myklebust
>>>> <Trond.Myklebust@netapp.com> wrote:
>>>>> On Mon, 2011-10-31 at 08:15 -0700, Peng Tao wrote:
>>>>>> For blocklayout, we need to issue layoutreturn to return layouts when
>>>>>> handling CB_RECALL_ANY.
>>>>>
>>>>> Why?
>>>> Because replying NFS4_OK to CB_RECALL_ANY indicates that client knows
>>>> that server wants client to return layout. And server will be waiting
>>>> for layoutreturn in such case.
>>>
>>> No it doesn't. NFS4_OK means that the client acknowledges that it has
>>> been given a new limit on the number of recallable objects it can keep.
>>> There is no requirement in the text that it should send layoutreturn or
>>> that the server should expect that.
>>
>> The motivation for CB_RECALL_ANY is to reduce the state on the *server* side.
>> Quoting from RFC5661:
>> The server may decide that it cannot hold all of the state for
>> recallable objects, such as delegations and layouts, without running
>> out of resources. In such a case, while not optimal, the server is
>> free to recall individual objects to reduce the load.
>> ...
>> In order to implement an effective reclaim scheme for such objects,
>> the server's knowledge of available resources must be used to
>> determine when objects must be recalled with the clients selecting
>> the actual objects to be returned.
>> ^^^^^^^^^^^^^^
>> ...
>> When a given resource pool is over-utilized, the server can send a
>> CB_RECALL_ANY to clients holding recallable objects of the types
>> involved, allowing it to keep a certain number of such objects and
>> return any excess.
>> ^^^^^^^^^^^^^^^^^
>> ...
>> RCA4_TYPE_MASK_FILE_LAYOUT
>>
>> The client is to return layouts of type LAYOUT4_NFSV4_1_FILES.
>> ^^^^^^^^^^^^^^^^^
>>
>> Isn't that explicit enough?
>
> Leaving aside the fact that the above quotes contain no normative
> language:
> Right now, we do a bulk return of all layouts. Doing a layoutreturn for
> each and every layout in that case is just ridiculous. Either do a
The idea is to return the layouts for files that are the least used,
not each and every layout.
> LAYOUTRETURN4_ALL after freeing all the layouts, or don't do anything at
> all and just wait for the server to revoke the layouts for us (which is
> what we currently do).
> Both options should be faster than doing a LAYOUTRETURN4_FILE on each
> and every file that is currently in use.
Doing LAYOUTRETURN4_ALL might cause a bug hiccup if the client needs to then send
a LAYOUTGET for each and every file that *is* currently in use.
So serving a CB_RECALL_ANY keeping more than 50% of the recallable objects means
the client would be better off returning the excess rather than returning everything
and reclaiming > 50% back.
Waiting for revocation may work well with some servers but would be disastrous in
terms of performance and responsiveness with others.
Benny
>
> Trond
>
^ permalink raw reply
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Andrea Arcangeli @ 2011-10-31 17:14 UTC (permalink / raw)
To: Nai Xia
Cc: Mel Gorman, Hugh Dickins, Pawel Sikora, Andrew Morton, linux-mm,
jpiszcz, arekm, linux-kernel
In-Reply-To: <201110221352.22741.nai.xia@gmail.com>
On Sat, Oct 22, 2011 at 01:52:22PM +0800, Nai Xia wrote:
> BTW, I am curious about what benchmark did you run and " x10 boost"
> meaning compared to Hugh's anon_vma_locking fix?
I was referring to the mremap optimizations I pushed in -mm.
> This patch and together with the reasoning looks good to me.
> But I wondering this patch can make the anon_vma chain ordering game more
> complex and harder to play in the future.
Well we don't know yet what future will bring... at least this adds
some documentation on the fact the order matters for
fork/mremap/migrate/split_huge_page. As far as I can tell they're the
4 pieces of the VM where the rmap_walk order matters. And
split_huge_page and migrate are the only two where if the rmap_walk
fails we can't safely continue and have to BUG_ON.
> However, if it does bring much perfomance benefit, I vote for this patch
> because it balances all three requirements here: bug free, performance &
> no two VMAs stay not merged for no good reason.
I suppose it should bring an SMP performance benefit as the critical
section is reduced but we'll have to do some more list_del/add_tail
than if we take the global lock...
> Our situation again makes me have the strong feeling that we are really
> in bad need of a computer aided way to travel all possible state space.
> There are some guys around me who do automatic software testing research.
> But I am afraid our problem is too much "real world" for them... sigh...
Also the code changes too fast for that...
I'll send the patch again with signoff.
^ permalink raw reply
* [PATCH] mremap: enforce rmap src/dst vma ordering in case of vma_merge succeeding in copy_vma
From: Andrea Arcangeli @ 2011-10-31 17:27 UTC (permalink / raw)
To: Mel Gorman
Cc: Nai Xia, Hugh Dickins, Pawel Sikora, Andrew Morton, linux-mm,
jpiszcz, arekm, linux-kernel
In-Reply-To: <20111031171441.GD3466@redhat.com>
migrate was doing a rmap_walk with speculative lock-less access on
pagetables. That could lead it to not serialize properly against
mremap PT locks. But a second problem remains in the order of vmas in
the same_anon_vma list used by the rmap_walk.
If vma_merge would succeed in copy_vma, the src vma could be placed
after the dst vma in the same_anon_vma list. That could still lead
migrate to miss some pte.
This patch adds a anon_vma_order_tail() function to force the dst vma
at the end of the list before mremap starts to solve the problem.
If the mremap is very large and there are a lots of parents or childs
sharing the anon_vma root lock, this should still scale better than
taking the anon_vma root lock around every pte copy practically for
the whole duration of mremap.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
include/linux/rmap.h | 1 +
mm/mmap.c | 8 ++++++++
mm/rmap.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 2148b12..45eb098 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -120,6 +120,7 @@ void anon_vma_init(void); /* create anon_vma_cachep */
int anon_vma_prepare(struct vm_area_struct *);
void unlink_anon_vmas(struct vm_area_struct *);
int anon_vma_clone(struct vm_area_struct *, struct vm_area_struct *);
+void anon_vma_order_tail(struct vm_area_struct *);
int anon_vma_fork(struct vm_area_struct *, struct vm_area_struct *);
void __anon_vma_link(struct vm_area_struct *);
diff --git a/mm/mmap.c b/mm/mmap.c
index a65efd4..a5858dc 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2339,7 +2339,15 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
*/
if (vma_start >= new_vma->vm_start &&
vma_start < new_vma->vm_end)
+ /*
+ * No need to call anon_vma_order_tail() in
+ * this case because the same PT lock will
+ * serialize the rmap_walk against both src
+ * and dst vmas.
+ */
*vmap = new_vma;
+ else
+ anon_vma_order_tail(new_vma);
} else {
new_vma = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (new_vma) {
diff --git a/mm/rmap.c b/mm/rmap.c
index 8005080..6dbc165 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -272,6 +272,50 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
}
/*
+ * Some rmap walk that needs to find all ptes/hugepmds without false
+ * negatives (like migrate and split_huge_page) running concurrent
+ * with operations that copy or move pagetables (like mremap() and
+ * fork()) to be safe depends the anon_vma "same_anon_vma" list to be
+ * in a certain order: the dst_vma must be placed after the src_vma in
+ * the list. This is always guaranteed by fork() but mremap() needs to
+ * call this function to enforce it in case the dst_vma isn't newly
+ * allocated and chained with the anon_vma_clone() function but just
+ * an extension of a pre-existing vma through vma_merge.
+ *
+ * NOTE: the same_anon_vma list can still be changed by other
+ * processes while mremap runs because mremap doesn't hold the
+ * anon_vma mutex to prevent modifications to the list while it
+ * runs. All we need to enforce is that the relative order of this
+ * process vmas isn't changing (we don't care about other vmas
+ * order). Each vma corresponds to an anon_vma_chain structure so
+ * there's no risk that other processes calling anon_vma_order_tail()
+ * and changing the same_anon_vma list under mremap() will screw with
+ * the relative order of this process vmas in the list, because we
+ * won't alter the order of any vma that isn't belonging to this
+ * process. And there can't be another anon_vma_order_tail running
+ * concurrently with mremap() coming from this process because we hold
+ * the mmap_sem for the whole mremap(). fork() ordering dependency
+ * also shouldn't be affected because we only care that the parent
+ * vmas are placed in the list before the child vmas and
+ * anon_vma_order_tail won't reorder vmas from either the fork parent
+ * or child.
+ */
+void anon_vma_order_tail(struct vm_area_struct *dst)
+{
+ struct anon_vma_chain *pavc;
+ struct anon_vma *root = NULL;
+
+ list_for_each_entry_reverse(pavc, &dst->anon_vma_chain, same_vma) {
+ struct anon_vma *anon_vma = pavc->anon_vma;
+ VM_BUG_ON(pavc->vma != dst);
+ root = lock_anon_vma_root(root, anon_vma);
+ list_del(&pavc->same_anon_vma);
+ list_add_tail(&pavc->same_anon_vma, &anon_vma->head);
+ }
+ unlock_anon_vma_root(root);
+}
+
+/*
* Attach vma to its own anon_vma, as well as to the anon_vmas that
* the corresponding VMA in the parent process is attached to.
* Returns 0 on success, non-zero on failure.
^ permalink raw reply related
* [PATCH] mremap: enforce rmap src/dst vma ordering in case of vma_merge succeeding in copy_vma
From: Andrea Arcangeli @ 2011-10-31 17:27 UTC (permalink / raw)
To: Mel Gorman
Cc: Nai Xia, Hugh Dickins, Pawel Sikora, Andrew Morton, linux-mm,
jpiszcz, arekm, linux-kernel
In-Reply-To: <20111031171441.GD3466@redhat.com>
migrate was doing a rmap_walk with speculative lock-less access on
pagetables. That could lead it to not serialize properly against
mremap PT locks. But a second problem remains in the order of vmas in
the same_anon_vma list used by the rmap_walk.
If vma_merge would succeed in copy_vma, the src vma could be placed
after the dst vma in the same_anon_vma list. That could still lead
migrate to miss some pte.
This patch adds a anon_vma_order_tail() function to force the dst vma
at the end of the list before mremap starts to solve the problem.
If the mremap is very large and there are a lots of parents or childs
sharing the anon_vma root lock, this should still scale better than
taking the anon_vma root lock around every pte copy practically for
the whole duration of mremap.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
include/linux/rmap.h | 1 +
mm/mmap.c | 8 ++++++++
mm/rmap.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 2148b12..45eb098 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -120,6 +120,7 @@ void anon_vma_init(void); /* create anon_vma_cachep */
int anon_vma_prepare(struct vm_area_struct *);
void unlink_anon_vmas(struct vm_area_struct *);
int anon_vma_clone(struct vm_area_struct *, struct vm_area_struct *);
+void anon_vma_order_tail(struct vm_area_struct *);
int anon_vma_fork(struct vm_area_struct *, struct vm_area_struct *);
void __anon_vma_link(struct vm_area_struct *);
diff --git a/mm/mmap.c b/mm/mmap.c
index a65efd4..a5858dc 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2339,7 +2339,15 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
*/
if (vma_start >= new_vma->vm_start &&
vma_start < new_vma->vm_end)
+ /*
+ * No need to call anon_vma_order_tail() in
+ * this case because the same PT lock will
+ * serialize the rmap_walk against both src
+ * and dst vmas.
+ */
*vmap = new_vma;
+ else
+ anon_vma_order_tail(new_vma);
} else {
new_vma = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (new_vma) {
diff --git a/mm/rmap.c b/mm/rmap.c
index 8005080..6dbc165 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -272,6 +272,50 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
}
/*
+ * Some rmap walk that needs to find all ptes/hugepmds without false
+ * negatives (like migrate and split_huge_page) running concurrent
+ * with operations that copy or move pagetables (like mremap() and
+ * fork()) to be safe depends the anon_vma "same_anon_vma" list to be
+ * in a certain order: the dst_vma must be placed after the src_vma in
+ * the list. This is always guaranteed by fork() but mremap() needs to
+ * call this function to enforce it in case the dst_vma isn't newly
+ * allocated and chained with the anon_vma_clone() function but just
+ * an extension of a pre-existing vma through vma_merge.
+ *
+ * NOTE: the same_anon_vma list can still be changed by other
+ * processes while mremap runs because mremap doesn't hold the
+ * anon_vma mutex to prevent modifications to the list while it
+ * runs. All we need to enforce is that the relative order of this
+ * process vmas isn't changing (we don't care about other vmas
+ * order). Each vma corresponds to an anon_vma_chain structure so
+ * there's no risk that other processes calling anon_vma_order_tail()
+ * and changing the same_anon_vma list under mremap() will screw with
+ * the relative order of this process vmas in the list, because we
+ * won't alter the order of any vma that isn't belonging to this
+ * process. And there can't be another anon_vma_order_tail running
+ * concurrently with mremap() coming from this process because we hold
+ * the mmap_sem for the whole mremap(). fork() ordering dependency
+ * also shouldn't be affected because we only care that the parent
+ * vmas are placed in the list before the child vmas and
+ * anon_vma_order_tail won't reorder vmas from either the fork parent
+ * or child.
+ */
+void anon_vma_order_tail(struct vm_area_struct *dst)
+{
+ struct anon_vma_chain *pavc;
+ struct anon_vma *root = NULL;
+
+ list_for_each_entry_reverse(pavc, &dst->anon_vma_chain, same_vma) {
+ struct anon_vma *anon_vma = pavc->anon_vma;
+ VM_BUG_ON(pavc->vma != dst);
+ root = lock_anon_vma_root(root, anon_vma);
+ list_del(&pavc->same_anon_vma);
+ list_add_tail(&pavc->same_anon_vma, &anon_vma->head);
+ }
+ unlock_anon_vma_root(root);
+}
+
+/*
* Attach vma to its own anon_vma, as well as to the anon_vmas that
* the corresponding VMA in the parent process is attached to.
* Returns 0 on success, non-zero on failure.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Andrea Arcangeli @ 2011-10-31 17:14 UTC (permalink / raw)
To: Nai Xia
Cc: Mel Gorman, Hugh Dickins, Pawel Sikora, Andrew Morton, linux-mm,
jpiszcz, arekm, linux-kernel
In-Reply-To: <201110221352.22741.nai.xia@gmail.com>
On Sat, Oct 22, 2011 at 01:52:22PM +0800, Nai Xia wrote:
> BTW, I am curious about what benchmark did you run and " x10 boost"
> meaning compared to Hugh's anon_vma_locking fix?
I was referring to the mremap optimizations I pushed in -mm.
> This patch and together with the reasoning looks good to me.
> But I wondering this patch can make the anon_vma chain ordering game more
> complex and harder to play in the future.
Well we don't know yet what future will bring... at least this adds
some documentation on the fact the order matters for
fork/mremap/migrate/split_huge_page. As far as I can tell they're the
4 pieces of the VM where the rmap_walk order matters. And
split_huge_page and migrate are the only two where if the rmap_walk
fails we can't safely continue and have to BUG_ON.
> However, if it does bring much perfomance benefit, I vote for this patch
> because it balances all three requirements here: bug free, performance &
> no two VMAs stay not merged for no good reason.
I suppose it should bring an SMP performance benefit as the critical
section is reduced but we'll have to do some more list_del/add_tail
than if we take the global lock...
> Our situation again makes me have the strong feeling that we are really
> in bad need of a computer aided way to travel all possible state space.
> There are some guys around me who do automatic software testing research.
> But I am afraid our problem is too much "real world" for them... sigh...
Also the code changes too fast for that...
I'll send the patch again with signoff.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [Qemu-devel] [PATCH v2] dma: Avoid reentrancy in DMA transfer handlers
From: Kevin Wolf @ 2011-10-31 16:44 UTC (permalink / raw)
To: qemu-devel; +Cc: kwolf, pbonzini
With the conversion of the block layer to coroutines, bdrv_read/write
have changed to run a nested event loop that calls qemu_bh_poll.
Consequently a scheduled BH can be called while a DMA transfer handler
runs and this means that DMA_run becomes reentrant.
Devices haven't been designed to cope with that, so instead of running a
nested transfer handler just wait for the next invocation of the BH from the
main loop.
This fixes some problems with the floppy device.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
hw/dma.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/dma.c b/hw/dma.c
index 8a7302a..0a9322d 100644
--- a/hw/dma.c
+++ b/hw/dma.c
@@ -358,6 +358,14 @@ static void DMA_run (void)
struct dma_cont *d;
int icont, ichan;
int rearm = 0;
+ static int running = 0;
+
+ if (running) {
+ rearm = 1;
+ goto out;
+ } else {
+ running = 1;
+ }
d = dma_controllers;
@@ -374,6 +382,8 @@ static void DMA_run (void)
}
}
+ running = 0;
+out:
if (rearm)
qemu_bh_schedule_idle(dma_bh);
}
--
1.7.6.4
^ permalink raw reply related
* Re: Flicker-free boot in DRM
From: Adam Jackson @ 2011-10-31 16:56 UTC (permalink / raw)
To: Keith Packard; +Cc: drivers, Intel
In-Reply-To: <yunk47n2jjv.fsf@aiko.keithp.com>
On 10/30/11 12:24 AM, Keith Packard wrote:
> On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard"<keithp@keithp.com> wrote:
>
>> * I've got LVDS pulling the current mode out of the hardware
>
> With a machine that has a native VBE mode for the panel, the problem is
> that clock computed from the hardware settings is not quite the same as
> the clock requested in the mode. I think the clock computation must be
> slightly off, but even with that fixed, it will probably not quite
> match. I think we'll need a magic flag in this mode telling DRM to allow
> a bit of fuzz in clock matching.
Yeah, it won't be precise. That's why there's PLL search code at all,
and why it has a fuzz factor for finding "good enough".
I ran the math for the maximum error in the PLL search back when I was
fixing a case where it fell through and failed to find timings at all.
See 6ba770dc5c334aff1c055c8728d34656e0f091e2.
- ajax
^ permalink raw reply
* Re: Flicker-free boot in DRM
From: Adam Jackson @ 2011-10-31 17:00 UTC (permalink / raw)
To: Keith Packard; +Cc: drivers, Intel
In-Reply-To: <yuny5w4qnv1.fsf@aiko.keithp.com>
On 10/29/11 3:05 AM, Keith Packard wrote:
> * Would UEFI do any better? It does provide a native mode on my MBA,
> it would be nice to know if this is at all common on regular PC
> hardware that has UEFI support.
UEFI firmwares are not required to get native mode on the panel right by
UEFI itself, I don't believe. But there are logo requirements programs
for some operating systems that require it, so it'll probably be quite
common.
- ajax
^ permalink raw reply
* Re: [meta-efl][meta-oe 05/12] id3lib: Import from openembedded classic
From: Koen Kooi @ 2011-10-31 17:48 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1320078283.3621.4.camel@mattotaupa>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Op 31-10-11 17:24, Paul Menzel schreef:
> Am Montag, den 31.10.2011, 11:50 +0100 schrieb Koen Kooi:
>> Op 29-10-11 14:33, Paul Menzel schreef:
>>> Dear Martin, dear Denis,
>>>
>>>
>>> Am Samstag, den 29.10.2011, 12:29 +0200 schrieb Martin Jansa:
>>>> From: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
>>>>
>>>> Added LIC_FILES_CHKSUM, and fixed LICENSE
>>>>
>>>> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
>>>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>>>
>>> NACK.
>>>
>>> please add the version you import and the commit ID you import from.
>>> This is all written in the guide lines [1]!
>>
>> And as I've said before, meta-oe is not oe-dev, so you can't use take
>> the old 'rules' and apply them to meta-oe 1:1!
>
> The guide lines I referred to [1] have been written for OE-core. ;-)
Yes, and oe-core still isn't meta-oe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org
iD8DBQFOrt9oMkyGM64RGpERAjfuAJ0f8N80qZ8LjF5XbW7lJ6Gl296cRACePnNK
h4DGgQIV9y/kR+YzHeVOWIA=
=QPHc
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Andrea Arcangeli @ 2011-10-31 16:34 UTC (permalink / raw)
To: Nai Xia
Cc: Mel Gorman, Hugh Dickins, Pawel Sikora, Andrew Morton, linux-mm,
jpiszcz, arekm, linux-kernel
In-Reply-To: <201110221307.11615.nai.xia@gmail.com>
Hi Nai,
On Sat, Oct 22, 2011 at 01:07:11PM +0800, Nai Xia wrote:
> Yeah, anon_vma root lock is a big lock. And JFYI, actually I am doing
> some very nasty hacking on anon_vma and one of the side effects is
> breaking the root lock into pieces. But this area is pretty
> convolved by many racing conditions. I hope some day I will finally make
> my patch work and have your precious review of it. :-)
:) It's going to be not trivial, initially it was not a shared lock
but it wasn't safe that way (especially with migrate required a
reliable rmap_walk) and using a shared lock across all
same_anon_vma/same_vma lists was the only way to be safe and solve the
races.
^ permalink raw reply
* Re: kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110
From: Andrea Arcangeli @ 2011-10-31 16:34 UTC (permalink / raw)
To: Nai Xia
Cc: Mel Gorman, Hugh Dickins, Pawel Sikora, Andrew Morton, linux-mm,
jpiszcz, arekm, linux-kernel
In-Reply-To: <201110221307.11615.nai.xia@gmail.com>
Hi Nai,
On Sat, Oct 22, 2011 at 01:07:11PM +0800, Nai Xia wrote:
> Yeah, anon_vma root lock is a big lock. And JFYI, actually I am doing
> some very nasty hacking on anon_vma and one of the side effects is
> breaking the root lock into pieces. But this area is pretty
> convolved by many racing conditions. I hope some day I will finally make
> my patch work and have your precious review of it. :-)
:) It's going to be not trivial, initially it was not a shared lock
but it wasn't safe that way (especially with migrate required a
reliable rmap_walk) and using a shared lock across all
same_anon_vma/same_vma lists was the only way to be safe and solve the
races.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
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.