* Re: [B.A.T.M.A.N.] [RFC 00/11] bridge loop avoidance II
From: Simon Wunderlich @ 2011-10-31 0:52 UTC (permalink / raw)
To: b.a.t.m.a.n
In-Reply-To: <1320015072-10313-1-git-send-email-siwu@hrz.tu-chemnitz.de>
[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]
Hey there,
There are also some online repositories which might be interesting for
your review:
http://git.open-mesh.org/?p=simon/batman-adv.git;a=shortlog;h=refs/heads/blaII_dirty
here are the separate fix patches on top of the original patchset. I'll add
fixes here first.
http://git.open-mesh.org/?p=simon/batman-adv.git;a=shortlog;h=refs/heads/blaII
this is the patchset as sent to the mailing list. Fixes are squashed from
blaII_dirty into this branch later.
http://git.open-mesh.org/?p=simon/batctl.git;a=shortlog;h=refs/heads/blaII
this is the batctl patch which adds some control and debugging functions.
Cheers,
Simon
On Sun, Oct 30, 2011 at 11:51:01PM +0100, Simon Wunderlich wrote:
> This series of patches is a request for comments on the redesigned
> bridge loop avoidance. The general concept is described in the wiki
> [1]. I've already performed a few testcases [2] which worked fine in
> my kvm environment. No crashes while running or unloading the
> extension either.
>
> The last patch in the series uses the cached address of the primary
> interface (the originator address known through the mesh) to save some
> code at various positions, there may be side effects I don't see
> however (e.g. implicit checking whether the module was configured
> correctly was removed).
>
> Marek already pointed quite a few issues out, these changes are
> reflected in the respective commit logs. These commit comments will
> be removed in the final version.
>
> Any comments and suggestions are appreciated.
>
> Thanks
> Simon
>
> [1] http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-II
> [2] http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-Testcases
>
> Simon Wunderlich (11):
> batman-adv: remove old bridge loop avoidance code
> batman-adv: add basic bridge loop avoidance code
> batman-adv: make bridge loop avoidance switchable
> batman-adv: export claim tables through debugfs
> batman-adv: allow multiple entries in tt_global_entries
> batman-adv: don't let backbone gateways exchange tt entries
> batman-adv: add broadcast duplicate check
> batman-adv: drop STP over batman
> batman-adv: form groups in the bridge loop avoidance
> batman-adv: Update README and sysfs description
> [RFC] batman-adv: get primaries address through bat_priv->own_orig
>
> Makefile.kbuild | 1 +
> README | 28 +-
> bat_debugfs.c | 18 +-
> bat_sysfs.c | 4 +-
> bridge_loop_avoidance.c | 1509 +++++++++++++++++++++++++++++++++++++++++++++++
> bridge_loop_avoidance.h | 34 ++
> compat.c | 16 +-
> compat.h | 3 +-
> hard-interface.c | 8 +-
> icmp_socket.c | 12 +-
> main.c | 9 +-
> main.h | 9 +-
> originator.c | 3 +-
> packet.h | 16 +
> routing.c | 41 +-
> soft-interface.c | 490 +---------------
> soft-interface.h | 2 -
> sysfs-class-net-mesh | 9 +
> translation-table.c | 366 ++++++++----
> types.h | 70 ++-
> unicast.c | 9 +-
> vis.c | 20 +-
> 22 files changed, 1965 insertions(+), 712 deletions(-)
> create mode 100644 bridge_loop_avoidance.c
> create mode 100644 bridge_loop_avoidance.h
>
> --
> 1.7.7.1
>
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Mike Frysinger @ 2011-10-31 0:54 UTC (permalink / raw)
To: u-boot
If we move the local funcs to the top of the file, and use the
__maybe_unused define, we can drop a lot of ugly ifdef logic and
duplicated prototypes.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
common/cmd_bdinfo.c | 89 ++++++++++++++++++--------------------------------
1 files changed, 32 insertions(+), 57 deletions(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index 688b238..67cb0da 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -26,24 +26,45 @@
*/
#include <common.h>
#include <command.h>
+#include <linux/compiler.h>
DECLARE_GLOBAL_DATA_PTR;
-static void print_num(const char *, ulong);
+__maybe_unused
+static void print_num(const char *name, ulong value)
+{
+ printf("%-12s= 0x%08lX\n", name, value);
+}
-#if !(defined(CONFIG_ARM) || defined(CONFIG_M68K) || defined(CONFIG_SANDBOX)) \
- || defined(CONFIG_CMD_NET)
-#define HAVE_PRINT_ETH
-static void print_eth(int idx);
-#endif
+__maybe_unused
+static void print_eth(int idx)
+{
+ char name[10], *val;
+ if (idx)
+ sprintf(name, "eth%iaddr", idx);
+ else
+ strcpy(name, "ethaddr");
+ val = getenv(name);
+ if (!val)
+ val = "(not set)";
+ printf("%-12s= %s\n", name, val);
+}
-#if (!defined(CONFIG_ARM) && !defined(CONFIG_X86) && !defined(CONFIG_SANDBOX))
-#define HAVE_PRINT_LNUM
-static void print_lnum(const char *, u64);
-#endif
+__maybe_unused
+static void print_lnum(const char *name, u64 value)
+{
+ printf("%-12s= 0x%.8llX\n", name, value);
+}
+
+__maybe_unused
+static void print_mhz(const char *name, unsigned long hz)
+{
+ char buf[32];
+
+ printf("%-12s= %6s MHz\n", name, strmhz(buf, hz));
+}
#if defined(CONFIG_PPC)
-static void print_mhz(const char *, unsigned long);
int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
@@ -208,8 +229,6 @@ int do_bdinfo(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
#elif defined(CONFIG_M68K)
-static void print_mhz(const char *, unsigned long);
-
int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
bd_t *bd = gd->bd;
@@ -257,8 +276,6 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
#elif defined(CONFIG_BLACKFIN)
-static void print_mhz(const char *, unsigned long);
-
int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
bd_t *bd = gd->bd;
@@ -377,8 +394,6 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
#elif defined(CONFIG_X86)
-static void print_mhz(const char *, unsigned long);
-
int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
int i;
@@ -464,46 +479,6 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
#error "a case for this architecture does not exist!"
#endif
-static void print_num(const char *name, ulong value)
-{
- printf("%-12s= 0x%08lX\n", name, value);
-}
-
-#ifdef HAVE_PRINT_ETH
-static void print_eth(int idx)
-{
- char name[10], *val;
- if (idx)
- sprintf(name, "eth%iaddr", idx);
- else
- strcpy(name, "ethaddr");
- val = getenv(name);
- if (!val)
- val = "(not set)";
- printf("%-12s= %s\n", name, val);
-}
-#endif
-
-#ifdef HAVE_PRINT_LNUM
-static void print_lnum(const char *name, u64 value)
-{
- printf("%-12s= 0x%.8llX\n", name, value);
-}
-#endif
-
-#if defined(CONFIG_PPC) || \
- defined(CONFIG_M68K) || \
- defined(CONFIG_BLACKFIN) || \
- defined(CONFIG_X86)
-static void print_mhz(const char *name, unsigned long hz)
-{
- char buf[32];
-
- printf("%-12s= %6s MHz\n", name, strmhz(buf, hz));
-}
-#endif /* CONFIG_PPC */
-
-
/* -------------------------------------------------------------------- */
U_BOOT_CMD(
--
1.7.6.1
^ permalink raw reply related
* Re: bigalloc and max file size
From: Theodore Tso @ 2011-10-30 19:49 UTC (permalink / raw)
To: i
Cc: Theodore Tso, Andreas Dilger, linux-ext4 development,
Alex Zhuravlev, Tao Ma, hao.bigrat@gmail.com
In-Reply-To: <4EACE2B7.9070402@coly.li>
On Oct 30, 2011, at 1:37 AM, Coly Li wrote:
> Forgive me if this is out of topic.
> In our test, allocating directories W/ bigalloc and W/O inline-data may occupy most of disk space. By now Ext4
> inline-data is not merged yet, I just wondering how Google uses bigalloc without inline-data patch set ?
It depends on how many directories you have (i.e, how deep your directory structure is) and how many small files you have in the file system as to whether bigalloc w/o inline-data has an acceptable overhead or not.
As I've noted before, for at least the last 7-8 years, and probably a decade, average seek times for 7200rpm drives have remained constant at 10ms, even as disk capacities have grown from 200GB in 2004, to 3TB in 2011. Yes, you can spin the platters faster, but the energy requirements go up with the square of the revolutions per minute, while the seek times only go up linearly; and so platter speeds don't get any faster than 15000rpm due to diminishing returns, and in fact some "green" drives only go at 5400rpm or even slower (interestingly enough, they tend not to advertise either the platter speed or the average seek time; funny, that….)
At 10ms per seek, that means that if the HDD isn't doing _anything_ else, it can do at most 100 seeks per second. Hence, if you have a workload where latency is at a premium, as disk capacities grow, disks are effectively getting slower for given data set size. For example, in 2004, if you wanted to serve 5TB of data, you'd need 25 200GB disks, so you had at your disposal 2500 random read/write operations per second at your disposal. In 2011, with 3TB disks, you'd have an order of magnitude fewer random writes when you only need to use 2 HDD's. (Yes, you could use flash, or flash-backed cache, but if the working set is really large this can get very expensive, so it's not a solution suitable for all situations.)
Another way of putting things is if latency really matters, and you have a random read/write workload, capacity management can become more about seeks than actual number of gigabytes. Hence, "wasting" space by using a larger cluster size may be a win if you are doing a large number of block allocations/deallocations, and memory pressure keeps on throwing the block bitmaps out of memory, so you have to keep seeking to read them back into memory. By using a large cluster size, we reduce fragmentation, and we reduce the number of block bitmaps, which makes them more likely to stay in memory.
Furthermore, reducing the number of the bitmap blocks makes it more tenable to pin them in memory, if there is a desire to guarantee that they stay in memory. (Dave Chinner was telling me that XFS manages its own metadata block lifespan, with its own shrinkers, instead of leaving when cached metadata gets ejected from memory. That might be worth doing at some point in ext4, but of course that would add complexity as well.)
The bottom line is that if you are seek constrained, wasting space by using a large cluster size may not be a huge concern. And if nearly all of your files are larger than 1MB, with many significantly larger, in-line data isn't going to help you a lot.
On the other hand, it may be that using 128 byte inode is a bigger win than using a larger inode size and storing the data in the inode table. Using a small inode size reduces metadata I/O by doubling the number of inodes/block compared to a 256 byte inode, never mind a 1k or 4k inode. Hence, if you don't need extended attributes or ACL's or sub-second timestamp resolution, you might want to consider using 128 byte inodes as possibly being a bigger win than in-line data. All of this requires benchmarking with your specific workload, of course.
I'm not against your patch set, however; I just haven't had time to look at them, at all (nor the secure delete patch set, etc.) . Between organizing the kernel summit, the kernel.org compromise, and some high priority bugs at $WORK, things have just been too busy. Sorry for that; I'll get to them after the merge window and post-merge bug fixing is under control.
-- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [meta-gnome] evince: initial add 2.32.0
From: Andreas Müller @ 2011-10-31 0:58 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1320003224-12913-1-git-send-email-schnitzeltony@gmx.de>
On Sunday, October 30, 2011 08:33:44 PM Andreas Müller wrote:
> * recipe based on oe-classic: evince_2.30.0.bb
> commit 5dba154457691d2096f2b1a7ef24bdc6f1b51859
> * run tested on overo
> * TODO further doctype support
> configure option -> current configure result
> ------------------------------------------------
> --enable-ps -> PostScript Backend.: no
> --enable-djvu -> DJVU Backend.......: no
> --enable-impress -> Impress Backend....: no
>
> Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
> ---
> meta-gnome/recipes-gnome/evince/evince_2.32.0.bb | 39
> ++++++++++++++++++++++ 1 files changed, 39 insertions(+), 0 deletions(-)
> create mode 100644 meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
>
> diff --git a/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
> b/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb new file mode 100644
> index 0000000..899d416
> --- /dev/null
> +++ b/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
> @@ -0,0 +1,39 @@
> +DESCRIPTION = "Evince is a document viewer for document formats like pdf,
> ps, djvu." +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=96f2f8d5ee576a2163977938ea36fa7b"
> +SECTION = "x11/office"
> +DEPENDS = "gnome-icon-theme gnome-doc-utils-native libgnome-keyring
> nautilus tiff libxt ghostscript poppler libxml2 gtk+ gconf libglade" +
> +inherit gnome pkgconfig gtk-icon-cache
> +
> +SRC_URI[archive.md5sum] = "ebc3ce6df8dcbf29cb9492f8dd031319"
> +SRC_URI[archive.sha256sum] =
> "2a4c91ae38f8b5028cebb91b9da9ddc50ea8ae3f3d429df89ba351da2d787ff7" +
> +EXTRA_OECONF = " --enable-thumbnailer \
> + --enable-nautilus \
> + --disable-scrollkeeper \
> + --enable-pixbuf \
> + "
> +
> +do_install_append() {
> + install -d install -d ${D}${datadir}/pixmaps
> + install -m 0755 ${S}/data/icons/48x48/apps/evince.png
> ${D}${datadir}/pixmaps/ +}
> +
> +RDEPENDS_${PN} += "glib-2.0-utils"
> +
> +PACKAGES =+ "${PN}-nautilus-extension"
> +FILES_${PN} += "${datadir}/dbus-1"
> +FILES_${PN}-dbg += "${libdir}/*/*/.debug \
> + ${libdir}/*/*/*/.debug"
> +FILES_${PN}-dev += "${libdir}/nautilus/extensions-2.0/*.la"
> +FILES_${PN}-staticdev += "${libdir}/nautilus/extensions-2.0/*.a"
> +FILES_${PN}-nautilus-extension = "${libdir}/nautilus/*/*so"
> +
> +pkg_postinst_${PN} () {
> +if [ -n "$D" ]; then
> + exit 1
> +fi
> +
> +glib-compile-schemas ${datadir}/glib-2.0/schemas
> +}
Be prepared that your system might feel different when installing evince and
starting *glib-compile-schemas* on pkg_postinst. It seems that now the files in
/usr/share/glib-2.0/schedule rise from dead by being compiled and thereby
causing new behaviours. E.g. When starting thunar for the first time in session I
now have to wait for very long and see
Out of memory: Kill process 1458 (gvfsd-smb-brows) score 742 or sacrifice child
Killed process 1458 (gvfsd-smb-brows) total-vm:403384kB, anon-rss:185676kB, file-
rss:108kB
gvfsd-smb-brows invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0,
oom_score_adj=0
[<c003f9bc>] (unwind_backtrace+0x0/0xe0) from [<c00a3020>]
(dump_header.clone.13+0x4c/0x11c)
[<c00a3020>] (dump_header.clone.13+0x4c/0x11c) from [<c00a31f0>]
(oom_kill_process.clone.16+0x3c/0x1e4)
[<c00a31f0>] (oom_kill_process.clone.16+0x3c/0x1e4) from [<c00a36f0>]
(out_of_memory+0x250/0x2d8)
[<c00a36f0>] (out_of_memory+0x250/0x2d8) from [<c00a658c>]
(__alloc_pages_nodemask+0x49c/0x614)
[<c00a658c>] (__alloc_pages_nodemask+0x49c/0x614) from [<c00a7e84>]
(__do_page_cache_readahead+0xa0/0x1e4)
[<c00a7e84>] (__do_page_cache_readahead+0xa0/0x1e4) from [<c00a8224>]
(ra_submit+0x20/0x24)
[<c00a8224>] (ra_submit+0x20/0x24) from [<c00a2704>] (filemap_fault+0x164/0x39c)
[<c00a2704>] (filemap_fault+0x164/0x39c) from [<c00b3e0c>]
(__do_fault+0x50/0x3a8)
[<c00b3e0c>] (__do_fault+0x50/0x3a8) from [<c00b68e4>]
(handle_pte_fault+0x23c/0x550)
[<c00b68e4>] (handle_pte_fault+0x23c/0x550) from [<c00b6c90>]
(handle_mm_fault+0x98/0xa8)
[<c00b6c90>] (handle_mm_fault+0x98/0xa8) from [<c00418f8>]
(do_page_fault+0xe0/0x268)
[<c00418f8>] (do_page_fault+0xe0/0x268) from [<c0036278>]
(do_PrefetchAbort+0x34/0x98)
[<c0036278>] (do_PrefetchAbort+0x34/0x98) from [<c003b460>]
(ret_from_exception+0x0/0x10)
Exception stack(0xcefb7fb0 to 0xcefb7ff8)
After a while a second thunar opens with contents at Network. This was empty
before!
Right now it again seems to me that opening one door causes entering a room with
many new doors...
Andreas
^ permalink raw reply
* Re: [patch 5/5]thp: split huge page if head page is isolated
From: Shaohua Li @ 2011-10-31 1:10 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, aarcange@redhat.com, Hugh Dickins, Rik van Riel,
mel, KAMEZAWA Hiroyuki, linux-mm, lkml
In-Reply-To: <20111028095040.GA31281@barrios-laptop.redhat.com>
On Fri, 2011-10-28 at 17:50 +0800, Minchan Kim wrote:
> On Fri, Oct 28, 2011 at 04:25:56PM +0800, Shaohua Li wrote:
> > On Fri, 2011-10-28 at 15:30 +0800, Minchan Kim wrote:
> > > On Fri, Oct 28, 2011 at 01:11:55PM +0800, Shaohua Li wrote:
> > > > On Fri, 2011-10-28 at 07:34 +0800, Minchan Kim wrote:
> > > > > On Tue, Oct 25, 2011 at 10:59:40AM +0800, Shaohua Li wrote:
> > > > > > With current logic, if page reclaim finds a huge page, it will just reclaim
> > > > > > the head page and leave tail pages reclaimed later. Let's take an example,
> > > > > > lru list has page A and B, page A is huge page:
> > > > > > 1. page A is isolated
> > > > > > 2. page B is isolated
> > > > > > 3. shrink_page_list() adds page A to swap page cache. so page A is split.
> > > > > > page A+1, page A+2, ... are added to lru list.
> > > > > > 4. shrink_page_list() adds page B to swap page cache.
> > > > > > 5. page A and B is written out and reclaimed.
> > > > > > 6. page A+1, A+2 ... is isolated and reclaimed later.
> > > > > > So the reclaim order is A, B, ...(maybe other pages), A+1, A+2 ...
> > > > >
> > > > > I don't see your code yet but have a question.
> > > > > You mitigate this problem by 4/5 which could add subpages into lru tail
> > > > > so subpages would reclaim next interation of reclaim.
> > > > >
> > > > > What do we need 5/5?
> > > > > Do I miss something?
> > > > Both patches are required. without this patch, current page reclaim will
> > > > only reclaim the first page of a huge page, because the hugepage isn't
> > > > split yet. The hugepage is split when the first page is being written to
> > > > swap, which is too later and page reclaim might already isolated a lot
> > > > of pages.
> > >
> > > When split happens, subpages would be located in tail of LRU by your 4/5.
> > > (Assume tail of LRU is old age).
> > yes, but a lot of other pages already isolated. we will reclaim those
> > pages first. for example, reclaim huge page A, B. current reclaim order
> > is A, B, A+1, ... B+1, because we will isolated A and B first, all tail
> > pages are not isolated yet. While with my patch, the order is A, A
> > +1, ... B, B+1,.... with my patch, we can avoid unnecessary page split
> > or page isolation. This is exactly why my patch reduces the thp_split
> > count.
>
> It's possbile but I doubt how it is effective becuase add_to_swap has a unlikely as follows
>
> if (unlikely(PageTransHuge(page)))
>
> I don't mean unlikely assumption is absolutely right.
> But at least, you have to convince us of it's wrong.
> Personally, I don't want to add more logic and handling THP pages
> different with normal page unless it's real concern.
if you actually use THP, you will find it's a problem. The data I posted
already clearly showed it.
^ permalink raw reply
* Re: [patch 5/5]thp: split huge page if head page is isolated
From: Shaohua Li @ 2011-10-31 1:10 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, aarcange@redhat.com, Hugh Dickins, Rik van Riel,
mel, KAMEZAWA Hiroyuki, linux-mm, lkml
In-Reply-To: <20111028095040.GA31281@barrios-laptop.redhat.com>
On Fri, 2011-10-28 at 17:50 +0800, Minchan Kim wrote:
> On Fri, Oct 28, 2011 at 04:25:56PM +0800, Shaohua Li wrote:
> > On Fri, 2011-10-28 at 15:30 +0800, Minchan Kim wrote:
> > > On Fri, Oct 28, 2011 at 01:11:55PM +0800, Shaohua Li wrote:
> > > > On Fri, 2011-10-28 at 07:34 +0800, Minchan Kim wrote:
> > > > > On Tue, Oct 25, 2011 at 10:59:40AM +0800, Shaohua Li wrote:
> > > > > > With current logic, if page reclaim finds a huge page, it will just reclaim
> > > > > > the head page and leave tail pages reclaimed later. Let's take an example,
> > > > > > lru list has page A and B, page A is huge page:
> > > > > > 1. page A is isolated
> > > > > > 2. page B is isolated
> > > > > > 3. shrink_page_list() adds page A to swap page cache. so page A is split.
> > > > > > page A+1, page A+2, ... are added to lru list.
> > > > > > 4. shrink_page_list() adds page B to swap page cache.
> > > > > > 5. page A and B is written out and reclaimed.
> > > > > > 6. page A+1, A+2 ... is isolated and reclaimed later.
> > > > > > So the reclaim order is A, B, ...(maybe other pages), A+1, A+2 ...
> > > > >
> > > > > I don't see your code yet but have a question.
> > > > > You mitigate this problem by 4/5 which could add subpages into lru tail
> > > > > so subpages would reclaim next interation of reclaim.
> > > > >
> > > > > What do we need 5/5?
> > > > > Do I miss something?
> > > > Both patches are required. without this patch, current page reclaim will
> > > > only reclaim the first page of a huge page, because the hugepage isn't
> > > > split yet. The hugepage is split when the first page is being written to
> > > > swap, which is too later and page reclaim might already isolated a lot
> > > > of pages.
> > >
> > > When split happens, subpages would be located in tail of LRU by your 4/5.
> > > (Assume tail of LRU is old age).
> > yes, but a lot of other pages already isolated. we will reclaim those
> > pages first. for example, reclaim huge page A, B. current reclaim order
> > is A, B, A+1, ... B+1, because we will isolated A and B first, all tail
> > pages are not isolated yet. While with my patch, the order is A, A
> > +1, ... B, B+1,.... with my patch, we can avoid unnecessary page split
> > or page isolation. This is exactly why my patch reduces the thp_split
> > count.
>
> It's possbile but I doubt how it is effective becuase add_to_swap has a unlikely as follows
>
> if (unlikely(PageTransHuge(page)))
>
> I don't mean unlikely assumption is absolutely right.
> But at least, you have to convince us of it's wrong.
> Personally, I don't want to add more logic and handling THP pages
> different with normal page unless it's real concern.
if you actually use THP, you will find it's a problem. The data I posted
already clearly showed it.
--
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
* Re: [patch 5/5]thp: split huge page if head page is isolated
From: Shaohua Li @ 2011-10-31 1:21 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, aarcange@redhat.com, Hugh Dickins, Rik van Riel,
mel, KAMEZAWA Hiroyuki, linux-mm, lkml
In-Reply-To: <20111029000624.GA1261@barrios-laptop.redhat.com>
On Sat, 2011-10-29 at 08:06 +0800, Minchan Kim wrote:
> On Tue, Oct 25, 2011 at 10:59:40AM +0800, Shaohua Li wrote:
> > With current logic, if page reclaim finds a huge page, it will just reclaim
> > the head page and leave tail pages reclaimed later. Let's take an example,
> > lru list has page A and B, page A is huge page:
> > 1. page A is isolated
> > 2. page B is isolated
> > 3. shrink_page_list() adds page A to swap page cache. so page A is split.
> > page A+1, page A+2, ... are added to lru list.
> > 4. shrink_page_list() adds page B to swap page cache.
> > 5. page A and B is written out and reclaimed.
> > 6. page A+1, A+2 ... is isolated and reclaimed later.
> > So the reclaim order is A, B, ...(maybe other pages), A+1, A+2 ...
> >
> > We expected the whole huge page A is reclaimed in the meantime, so
> > the order is A, A+1, ... A+HPAGE_PMD_NR-1, B, ....
> >
> > With this patch, we do huge page split just after the head page is isolated
> > for inactive lru list, so the tail pages will be reclaimed immediately.
> >
> > In a test, a range of anonymous memory is written and will trigger swap.
> > Without the patch:
> > #cat /proc/vmstat|grep thp
> > thp_fault_alloc 451
> > thp_fault_fallback 0
> > thp_collapse_alloc 0
> > thp_collapse_alloc_failed 0
> > thp_split 238
> >
> > With the patch:
> > #cat /proc/vmstat|grep thp
> > thp_fault_alloc 450
> > thp_fault_fallback 1
> > thp_collapse_alloc 0
> > thp_collapse_alloc_failed 0
> > thp_split 103
> >
> > So the thp_split number is reduced a lot, though there is one extra
> > thp_fault_fallback.
> >
> > Signed-off-by: Shaohua Li <shaohua.li@intel.com>
> > ---
> > include/linux/memcontrol.h | 3 +-
> > mm/memcontrol.c | 12 +++++++++--
> > mm/vmscan.c | 49 ++++++++++++++++++++++++++++++++++-----------
> > 3 files changed, 50 insertions(+), 14 deletions(-)
> >
> > Index: linux/mm/vmscan.c
> > ===================================================================
> > --- linux.orig/mm/vmscan.c 2011-10-25 08:36:08.000000000 +0800
> > +++ linux/mm/vmscan.c 2011-10-25 09:51:44.000000000 +0800
> > @@ -1076,7 +1076,8 @@ int __isolate_lru_page(struct page *page
> > */
> > static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
> > struct list_head *src, struct list_head *dst,
> > - unsigned long *scanned, int order, int mode, int file)
> > + unsigned long *scanned, int order, int mode, int file,
> > + struct page **split_page)
> > {
> > unsigned long nr_taken = 0;
> > unsigned long nr_lumpy_taken = 0;
> > @@ -1100,7 +1101,12 @@ static unsigned long isolate_lru_pages(u
> > case 0:
> > list_move(&page->lru, dst);
> > mem_cgroup_del_lru(page);
> > - nr_taken += hpage_nr_pages(page);
> > + if (PageTransHuge(page) && split_page) {
> > + nr_taken++;
> > + *split_page = page;
> > + goto out;
> > + } else
> > + nr_taken += hpage_nr_pages(page);
> > break;
> >
> > case -EBUSY:
> > @@ -1158,11 +1164,16 @@ static unsigned long isolate_lru_pages(u
> > if (__isolate_lru_page(cursor_page, mode, file) == 0) {
> > list_move(&cursor_page->lru, dst);
> > mem_cgroup_del_lru(cursor_page);
> > - nr_taken += hpage_nr_pages(page);
> > nr_lumpy_taken++;
> > if (PageDirty(cursor_page))
> > nr_lumpy_dirty++;
> > scan++;
> > + if (PageTransHuge(page) && split_page) {
> > + nr_taken++;
> > + *split_page = page;
> > + goto out;
> > + } else
> > + nr_taken += hpage_nr_pages(page);
> > } else {
> > /*
> > * Check if the page is freed already.
> > @@ -1188,6 +1199,7 @@ static unsigned long isolate_lru_pages(u
> > nr_lumpy_failed++;
> > }
> >
> > +out:
> > *scanned = scan;
> >
> > trace_mm_vmscan_lru_isolate(order,
> > @@ -1202,7 +1214,8 @@ static unsigned long isolate_pages_globa
> > struct list_head *dst,
> > unsigned long *scanned, int order,
> > int mode, struct zone *z,
> > - int active, int file)
> > + int active, int file,
> > + struct page **split_page)
> > {
> > int lru = LRU_BASE;
> > if (active)
> > @@ -1210,7 +1223,7 @@ static unsigned long isolate_pages_globa
> > if (file)
> > lru += LRU_FILE;
> > return isolate_lru_pages(nr, &z->lru[lru].list, dst, scanned, order,
> > - mode, file);
> > + mode, file, split_page);
> > }
> >
> > /*
> > @@ -1444,10 +1457,12 @@ shrink_inactive_list(unsigned long nr_to
> > {
> > LIST_HEAD(page_list);
> > unsigned long nr_scanned;
> > + unsigned long total_scanned = 0;
> > unsigned long nr_reclaimed = 0;
> > unsigned long nr_taken;
> > unsigned long nr_anon;
> > unsigned long nr_file;
> > + struct page *split_page;
> >
> > while (unlikely(too_many_isolated(zone, file, sc))) {
> > congestion_wait(BLK_RW_ASYNC, HZ/10);
> > @@ -1458,16 +1473,19 @@ shrink_inactive_list(unsigned long nr_to
> > }
> >
> > set_reclaim_mode(priority, sc, false);
> > +again:
> > lru_add_drain();
> > + split_page = NULL;
> > spin_lock_irq(&zone->lru_lock);
> >
> > if (scanning_global_lru(sc)) {
> > - nr_taken = isolate_pages_global(nr_to_scan,
> > + nr_taken = isolate_pages_global(nr_to_scan - total_scanned,
> > &page_list, &nr_scanned, sc->order,
> > sc->reclaim_mode & RECLAIM_MODE_LUMPYRECLAIM ?
> > ISOLATE_BOTH : ISOLATE_INACTIVE,
> > - zone, 0, file);
> > + zone, 0, file, &split_page);
> > zone->pages_scanned += nr_scanned;
> > + total_scanned += nr_scanned;
> > if (current_is_kswapd())
> > __count_zone_vm_events(PGSCAN_KSWAPD, zone,
> > nr_scanned);
> > @@ -1475,12 +1493,13 @@ shrink_inactive_list(unsigned long nr_to
> > __count_zone_vm_events(PGSCAN_DIRECT, zone,
> > nr_scanned);
> > } else {
> > - nr_taken = mem_cgroup_isolate_pages(nr_to_scan,
> > + nr_taken = mem_cgroup_isolate_pages(nr_to_scan - total_scanned,
> > &page_list, &nr_scanned, sc->order,
> > sc->reclaim_mode & RECLAIM_MODE_LUMPYRECLAIM ?
> > ISOLATE_BOTH : ISOLATE_INACTIVE,
> > zone, sc->mem_cgroup,
> > - 0, file);
> > + 0, file, &split_page);
> > + total_scanned += nr_scanned;
> > /*
> > * mem_cgroup_isolate_pages() keeps track of
> > * scanned pages on its own.
> > @@ -1491,11 +1510,19 @@ shrink_inactive_list(unsigned long nr_to
> > spin_unlock_irq(&zone->lru_lock);
> > return 0;
> > }
> > + if (split_page && total_scanned < nr_to_scan) {
> > + spin_unlock_irq(&zone->lru_lock);
> > + split_huge_page(split_page);
> > + goto again;
> > + }
> >
> > update_isolated_counts(zone, sc, &nr_anon, &nr_file, &page_list);
> >
> > spin_unlock_irq(&zone->lru_lock);
> >
> > + if (split_page)
> > + split_huge_page(split_page);
> > +
> > nr_reclaimed = shrink_page_list(&page_list, zone, sc);
> >
> > /* Check if we should syncronously wait for writeback */
> > @@ -1589,13 +1616,13 @@ static void shrink_active_list(unsigned
> > nr_taken = isolate_pages_global(nr_pages, &l_hold,
> > &pgscanned, sc->order,
> > ISOLATE_ACTIVE, zone,
> > - 1, file);
> > + 1, file, NULL);
> > zone->pages_scanned += pgscanned;
> > } else {
> > nr_taken = mem_cgroup_isolate_pages(nr_pages, &l_hold,
> > &pgscanned, sc->order,
> > ISOLATE_ACTIVE, zone,
> > - sc->mem_cgroup, 1, file);
> > + sc->mem_cgroup, 1, file, NULL);
> > /*
> > * mem_cgroup_isolate_pages() keeps track of
> > * scanned pages on its own.
> > Index: linux/mm/memcontrol.c
> > ===================================================================
> > --- linux.orig/mm/memcontrol.c 2011-10-25 08:36:08.000000000 +0800
> > +++ linux/mm/memcontrol.c 2011-10-25 09:33:51.000000000 +0800
> > @@ -1187,7 +1187,8 @@ unsigned long mem_cgroup_isolate_pages(u
> > unsigned long *scanned, int order,
> > int mode, struct zone *z,
> > struct mem_cgroup *mem_cont,
> > - int active, int file)
> > + int active, int file,
> > + struct page **split_page)
> > {
> > unsigned long nr_taken = 0;
> > struct page *page;
> > @@ -1224,7 +1225,13 @@ unsigned long mem_cgroup_isolate_pages(u
> > case 0:
> > list_move(&page->lru, dst);
> > mem_cgroup_del_lru(page);
> > - nr_taken += hpage_nr_pages(page);
> > + if (PageTransHuge(page) && split_page) {
> > + nr_taken++;
> > + *split_page = page;
> > + goto out;
> > + } else
> > + nr_taken += hpage_nr_pages(page);
> > +
> > break;
> > case -EBUSY:
> > /* we don't affect global LRU but rotate in our LRU */
> > @@ -1235,6 +1242,7 @@ unsigned long mem_cgroup_isolate_pages(u
> > }
> > }
> >
> > +out:
> > *scanned = scan;
> >
> > trace_mm_vmscan_memcg_isolate(0, nr_to_scan, scan, nr_taken,
> > Index: linux/include/linux/memcontrol.h
> > ===================================================================
> > --- linux.orig/include/linux/memcontrol.h 2011-10-25 08:36:08.000000000 +0800
> > +++ linux/include/linux/memcontrol.h 2011-10-25 09:33:51.000000000 +0800
> > @@ -37,7 +37,8 @@ extern unsigned long mem_cgroup_isolate_
> > unsigned long *scanned, int order,
> > int mode, struct zone *z,
> > struct mem_cgroup *mem_cont,
> > - int active, int file);
> > + int active, int file,
> > + struct page **split_page);
> >
> > #ifdef CONFIG_CGROUP_MEM_RES_CTLR
> > /*
> >
> >
>
> I saw the code. my concern is your patch could make unnecessary split of THP.
>
> When we isolates page, we can't know whether it's working set or not.
> So split should happen after we judge it's working set page.
yes, but since memory is big currently, it's unlikely the isolated page
get accessed in the window. And I only did the split in
shrink_inactive_list, not in active list.
And THP has mechanism to collapse small pages to huge page later.
> If you really want to merge this patch, I suggest that
> we can handle it in shrink_page_list step, not isolation step.
>
> My totally untested code which is just to show the concept is as follows,
I did consider this option before. It has its problem too. The isolation
can isolate several huge page one time. And then later shrink_page_list
can swap several huge page one time, which is unfortunate. I'm pretty
sure this method can't reduce the thp_split count in my test. It could
be helpful when pages are heavily rotated, but this means page reclaim
is already broken, which is rare case.
--
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
* Re: [patch 5/5]thp: split huge page if head page is isolated
From: Shaohua Li @ 2011-10-31 1:21 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, aarcange@redhat.com, Hugh Dickins, Rik van Riel,
mel, KAMEZAWA Hiroyuki, linux-mm, lkml
In-Reply-To: <20111029000624.GA1261@barrios-laptop.redhat.com>
On Sat, 2011-10-29 at 08:06 +0800, Minchan Kim wrote:
> On Tue, Oct 25, 2011 at 10:59:40AM +0800, Shaohua Li wrote:
> > With current logic, if page reclaim finds a huge page, it will just reclaim
> > the head page and leave tail pages reclaimed later. Let's take an example,
> > lru list has page A and B, page A is huge page:
> > 1. page A is isolated
> > 2. page B is isolated
> > 3. shrink_page_list() adds page A to swap page cache. so page A is split.
> > page A+1, page A+2, ... are added to lru list.
> > 4. shrink_page_list() adds page B to swap page cache.
> > 5. page A and B is written out and reclaimed.
> > 6. page A+1, A+2 ... is isolated and reclaimed later.
> > So the reclaim order is A, B, ...(maybe other pages), A+1, A+2 ...
> >
> > We expected the whole huge page A is reclaimed in the meantime, so
> > the order is A, A+1, ... A+HPAGE_PMD_NR-1, B, ....
> >
> > With this patch, we do huge page split just after the head page is isolated
> > for inactive lru list, so the tail pages will be reclaimed immediately.
> >
> > In a test, a range of anonymous memory is written and will trigger swap.
> > Without the patch:
> > #cat /proc/vmstat|grep thp
> > thp_fault_alloc 451
> > thp_fault_fallback 0
> > thp_collapse_alloc 0
> > thp_collapse_alloc_failed 0
> > thp_split 238
> >
> > With the patch:
> > #cat /proc/vmstat|grep thp
> > thp_fault_alloc 450
> > thp_fault_fallback 1
> > thp_collapse_alloc 0
> > thp_collapse_alloc_failed 0
> > thp_split 103
> >
> > So the thp_split number is reduced a lot, though there is one extra
> > thp_fault_fallback.
> >
> > Signed-off-by: Shaohua Li <shaohua.li@intel.com>
> > ---
> > include/linux/memcontrol.h | 3 +-
> > mm/memcontrol.c | 12 +++++++++--
> > mm/vmscan.c | 49 ++++++++++++++++++++++++++++++++++-----------
> > 3 files changed, 50 insertions(+), 14 deletions(-)
> >
> > Index: linux/mm/vmscan.c
> > ===================================================================
> > --- linux.orig/mm/vmscan.c 2011-10-25 08:36:08.000000000 +0800
> > +++ linux/mm/vmscan.c 2011-10-25 09:51:44.000000000 +0800
> > @@ -1076,7 +1076,8 @@ int __isolate_lru_page(struct page *page
> > */
> > static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
> > struct list_head *src, struct list_head *dst,
> > - unsigned long *scanned, int order, int mode, int file)
> > + unsigned long *scanned, int order, int mode, int file,
> > + struct page **split_page)
> > {
> > unsigned long nr_taken = 0;
> > unsigned long nr_lumpy_taken = 0;
> > @@ -1100,7 +1101,12 @@ static unsigned long isolate_lru_pages(u
> > case 0:
> > list_move(&page->lru, dst);
> > mem_cgroup_del_lru(page);
> > - nr_taken += hpage_nr_pages(page);
> > + if (PageTransHuge(page) && split_page) {
> > + nr_taken++;
> > + *split_page = page;
> > + goto out;
> > + } else
> > + nr_taken += hpage_nr_pages(page);
> > break;
> >
> > case -EBUSY:
> > @@ -1158,11 +1164,16 @@ static unsigned long isolate_lru_pages(u
> > if (__isolate_lru_page(cursor_page, mode, file) == 0) {
> > list_move(&cursor_page->lru, dst);
> > mem_cgroup_del_lru(cursor_page);
> > - nr_taken += hpage_nr_pages(page);
> > nr_lumpy_taken++;
> > if (PageDirty(cursor_page))
> > nr_lumpy_dirty++;
> > scan++;
> > + if (PageTransHuge(page) && split_page) {
> > + nr_taken++;
> > + *split_page = page;
> > + goto out;
> > + } else
> > + nr_taken += hpage_nr_pages(page);
> > } else {
> > /*
> > * Check if the page is freed already.
> > @@ -1188,6 +1199,7 @@ static unsigned long isolate_lru_pages(u
> > nr_lumpy_failed++;
> > }
> >
> > +out:
> > *scanned = scan;
> >
> > trace_mm_vmscan_lru_isolate(order,
> > @@ -1202,7 +1214,8 @@ static unsigned long isolate_pages_globa
> > struct list_head *dst,
> > unsigned long *scanned, int order,
> > int mode, struct zone *z,
> > - int active, int file)
> > + int active, int file,
> > + struct page **split_page)
> > {
> > int lru = LRU_BASE;
> > if (active)
> > @@ -1210,7 +1223,7 @@ static unsigned long isolate_pages_globa
> > if (file)
> > lru += LRU_FILE;
> > return isolate_lru_pages(nr, &z->lru[lru].list, dst, scanned, order,
> > - mode, file);
> > + mode, file, split_page);
> > }
> >
> > /*
> > @@ -1444,10 +1457,12 @@ shrink_inactive_list(unsigned long nr_to
> > {
> > LIST_HEAD(page_list);
> > unsigned long nr_scanned;
> > + unsigned long total_scanned = 0;
> > unsigned long nr_reclaimed = 0;
> > unsigned long nr_taken;
> > unsigned long nr_anon;
> > unsigned long nr_file;
> > + struct page *split_page;
> >
> > while (unlikely(too_many_isolated(zone, file, sc))) {
> > congestion_wait(BLK_RW_ASYNC, HZ/10);
> > @@ -1458,16 +1473,19 @@ shrink_inactive_list(unsigned long nr_to
> > }
> >
> > set_reclaim_mode(priority, sc, false);
> > +again:
> > lru_add_drain();
> > + split_page = NULL;
> > spin_lock_irq(&zone->lru_lock);
> >
> > if (scanning_global_lru(sc)) {
> > - nr_taken = isolate_pages_global(nr_to_scan,
> > + nr_taken = isolate_pages_global(nr_to_scan - total_scanned,
> > &page_list, &nr_scanned, sc->order,
> > sc->reclaim_mode & RECLAIM_MODE_LUMPYRECLAIM ?
> > ISOLATE_BOTH : ISOLATE_INACTIVE,
> > - zone, 0, file);
> > + zone, 0, file, &split_page);
> > zone->pages_scanned += nr_scanned;
> > + total_scanned += nr_scanned;
> > if (current_is_kswapd())
> > __count_zone_vm_events(PGSCAN_KSWAPD, zone,
> > nr_scanned);
> > @@ -1475,12 +1493,13 @@ shrink_inactive_list(unsigned long nr_to
> > __count_zone_vm_events(PGSCAN_DIRECT, zone,
> > nr_scanned);
> > } else {
> > - nr_taken = mem_cgroup_isolate_pages(nr_to_scan,
> > + nr_taken = mem_cgroup_isolate_pages(nr_to_scan - total_scanned,
> > &page_list, &nr_scanned, sc->order,
> > sc->reclaim_mode & RECLAIM_MODE_LUMPYRECLAIM ?
> > ISOLATE_BOTH : ISOLATE_INACTIVE,
> > zone, sc->mem_cgroup,
> > - 0, file);
> > + 0, file, &split_page);
> > + total_scanned += nr_scanned;
> > /*
> > * mem_cgroup_isolate_pages() keeps track of
> > * scanned pages on its own.
> > @@ -1491,11 +1510,19 @@ shrink_inactive_list(unsigned long nr_to
> > spin_unlock_irq(&zone->lru_lock);
> > return 0;
> > }
> > + if (split_page && total_scanned < nr_to_scan) {
> > + spin_unlock_irq(&zone->lru_lock);
> > + split_huge_page(split_page);
> > + goto again;
> > + }
> >
> > update_isolated_counts(zone, sc, &nr_anon, &nr_file, &page_list);
> >
> > spin_unlock_irq(&zone->lru_lock);
> >
> > + if (split_page)
> > + split_huge_page(split_page);
> > +
> > nr_reclaimed = shrink_page_list(&page_list, zone, sc);
> >
> > /* Check if we should syncronously wait for writeback */
> > @@ -1589,13 +1616,13 @@ static void shrink_active_list(unsigned
> > nr_taken = isolate_pages_global(nr_pages, &l_hold,
> > &pgscanned, sc->order,
> > ISOLATE_ACTIVE, zone,
> > - 1, file);
> > + 1, file, NULL);
> > zone->pages_scanned += pgscanned;
> > } else {
> > nr_taken = mem_cgroup_isolate_pages(nr_pages, &l_hold,
> > &pgscanned, sc->order,
> > ISOLATE_ACTIVE, zone,
> > - sc->mem_cgroup, 1, file);
> > + sc->mem_cgroup, 1, file, NULL);
> > /*
> > * mem_cgroup_isolate_pages() keeps track of
> > * scanned pages on its own.
> > Index: linux/mm/memcontrol.c
> > ===================================================================
> > --- linux.orig/mm/memcontrol.c 2011-10-25 08:36:08.000000000 +0800
> > +++ linux/mm/memcontrol.c 2011-10-25 09:33:51.000000000 +0800
> > @@ -1187,7 +1187,8 @@ unsigned long mem_cgroup_isolate_pages(u
> > unsigned long *scanned, int order,
> > int mode, struct zone *z,
> > struct mem_cgroup *mem_cont,
> > - int active, int file)
> > + int active, int file,
> > + struct page **split_page)
> > {
> > unsigned long nr_taken = 0;
> > struct page *page;
> > @@ -1224,7 +1225,13 @@ unsigned long mem_cgroup_isolate_pages(u
> > case 0:
> > list_move(&page->lru, dst);
> > mem_cgroup_del_lru(page);
> > - nr_taken += hpage_nr_pages(page);
> > + if (PageTransHuge(page) && split_page) {
> > + nr_taken++;
> > + *split_page = page;
> > + goto out;
> > + } else
> > + nr_taken += hpage_nr_pages(page);
> > +
> > break;
> > case -EBUSY:
> > /* we don't affect global LRU but rotate in our LRU */
> > @@ -1235,6 +1242,7 @@ unsigned long mem_cgroup_isolate_pages(u
> > }
> > }
> >
> > +out:
> > *scanned = scan;
> >
> > trace_mm_vmscan_memcg_isolate(0, nr_to_scan, scan, nr_taken,
> > Index: linux/include/linux/memcontrol.h
> > ===================================================================
> > --- linux.orig/include/linux/memcontrol.h 2011-10-25 08:36:08.000000000 +0800
> > +++ linux/include/linux/memcontrol.h 2011-10-25 09:33:51.000000000 +0800
> > @@ -37,7 +37,8 @@ extern unsigned long mem_cgroup_isolate_
> > unsigned long *scanned, int order,
> > int mode, struct zone *z,
> > struct mem_cgroup *mem_cont,
> > - int active, int file);
> > + int active, int file,
> > + struct page **split_page);
> >
> > #ifdef CONFIG_CGROUP_MEM_RES_CTLR
> > /*
> >
> >
>
> I saw the code. my concern is your patch could make unnecessary split of THP.
>
> When we isolates page, we can't know whether it's working set or not.
> So split should happen after we judge it's working set page.
yes, but since memory is big currently, it's unlikely the isolated page
get accessed in the window. And I only did the split in
shrink_inactive_list, not in active list.
And THP has mechanism to collapse small pages to huge page later.
> If you really want to merge this patch, I suggest that
> we can handle it in shrink_page_list step, not isolation step.
>
> My totally untested code which is just to show the concept is as follows,
I did consider this option before. It has its problem too. The isolation
can isolate several huge page one time. And then later shrink_page_list
can swap several huge page one time, which is unfortunate. I'm pretty
sure this method can't reduce the thp_split count in my test. It could
be helpful when pages are heavily rotated, but this means page reclaim
is already broken, which is rare case.
^ permalink raw reply
* Re: [ANNOUNCE] xf86-video-intel 2.16.901
From: Bojan Smojver @ 2011-10-31 1:15 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20111030165702.GA16833@cantiga.alporthouse.com>
On Sun, 2011-10-30 at 16:57 +0000, Chris Wilson wrote:
> Bugs fixed in this snapshot (compared to 2.16.0)
No hibernation memory corruption fix. Sniff, sniff... :-(
--
Bojan
^ permalink raw reply
* [PATCH v2] drm/i915: Fix recursive calls to unmap
From: Ben Widawsky @ 2011-10-31 1:20 UTC (permalink / raw)
To: intel-gfx; +Cc: Ben Widawsky
After the ILK vt-d workaround patches it became clear that we had
introduced a bug. Chris tracked down the issue to recursive calls to
unmap. This happens because we try to optimize waiting on requests by
calling retire requests after the wait, which may drop the last
reference on an object and end up freeing the object (and then unmap the
object from the gtt).
The solution here is to add a new flag to the call chain which gives the
routines the information they need to possibly defer actions which may
cause us to recurse.
Kudos to Chris for tracking this one down.
This fixes tests/gem_linear_blits in intel-gpu-tools.
v2: v1 used a global, v2 directly modified the call chain.
Cc: Keith Packard <keithp@keithp.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: guang.a.yang@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42180
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++++--
drivers/gpu/drm/i915/i915_gem.c | 24 ++++++++++++++----------
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/intel_overlay.c | 4 ++--
4 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 06a37f4..35ad8f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1180,13 +1180,15 @@ void i915_gem_do_init(struct drm_device *dev,
unsigned long start,
unsigned long mappable_end,
unsigned long end);
-int __must_check i915_gpu_idle(struct drm_device *dev);
+int __must_check i915_gem_gpu_idle(struct drm_device *dev, bool strictly_idle);
+#define i915_gpu_idle(dev) i915_gem_gpu_idle(dev, false)
int __must_check i915_gem_idle(struct drm_device *dev);
int __must_check i915_add_request(struct intel_ring_buffer *ring,
struct drm_file *file,
struct drm_i915_gem_request *request);
int __must_check i915_wait_request(struct intel_ring_buffer *ring,
- uint32_t seqno);
+ uint32_t seqno,
+ bool defer_retirement);
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
int __must_check
i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6651c36..70c72ac 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1943,7 +1943,8 @@ i915_gem_retire_work_handler(struct work_struct *work)
*/
int
i915_wait_request(struct intel_ring_buffer *ring,
- uint32_t seqno)
+ uint32_t seqno,
+ bool defer_retirement)
{
drm_i915_private_t *dev_priv = ring->dev->dev_private;
u32 ier;
@@ -2027,7 +2028,7 @@ i915_wait_request(struct intel_ring_buffer *ring,
* buffer to have made it to the inactive list, and we would need
* a separate wait queue to handle that.
*/
- if (ret == 0)
+ if (ret == 0 && !defer_retirement)
i915_gem_retire_requests_ring(ring);
return ret;
@@ -2051,7 +2052,8 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj)
* it.
*/
if (obj->active) {
- ret = i915_wait_request(obj->ring, obj->last_rendering_seqno);
+ ret = i915_wait_request(obj->ring, obj->last_rendering_seqno,
+ true);
if (ret)
return ret;
}
@@ -2172,7 +2174,7 @@ i915_gem_flush_ring(struct intel_ring_buffer *ring,
return 0;
}
-static int i915_ring_idle(struct intel_ring_buffer *ring)
+static int i915_ring_idle(struct intel_ring_buffer *ring, bool defer_retirement)
{
int ret;
@@ -2186,18 +2188,18 @@ static int i915_ring_idle(struct intel_ring_buffer *ring)
return ret;
}
- return i915_wait_request(ring, i915_gem_next_request_seqno(ring));
+ return i915_wait_request(ring, i915_gem_next_request_seqno(ring),
+ defer_retirement);
}
-int
-i915_gpu_idle(struct drm_device *dev)
+int i915_gem_gpu_idle(struct drm_device *dev, bool strictly_idle)
{
drm_i915_private_t *dev_priv = dev->dev_private;
int ret, i;
/* Flush everything onto the inactive list. */
for (i = 0; i < I915_NUM_RINGS; i++) {
- ret = i915_ring_idle(&dev_priv->ring[i]);
+ ret = i915_ring_idle(&dev_priv->ring[i], strictly_idle);
if (ret)
return ret;
}
@@ -2400,7 +2402,8 @@ i915_gem_object_flush_fence(struct drm_i915_gem_object *obj,
if (!ring_passed_seqno(obj->last_fenced_ring,
obj->last_fenced_seqno)) {
ret = i915_wait_request(obj->last_fenced_ring,
- obj->last_fenced_seqno);
+ obj->last_fenced_seqno,
+ true);
if (ret)
return ret;
}
@@ -2541,7 +2544,8 @@ i915_gem_object_get_fence(struct drm_i915_gem_object *obj,
if (!ring_passed_seqno(obj->last_fenced_ring,
reg->setup_seqno)) {
ret = i915_wait_request(obj->last_fenced_ring,
- reg->setup_seqno);
+ reg->setup_seqno,
+ true);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6042c5e..b90b547 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -55,7 +55,7 @@ static bool do_idling(struct drm_i915_private *dev_priv)
if (unlikely(dev_priv->mm.gtt->do_idle_maps)) {
dev_priv->mm.interruptible = false;
- if (i915_gpu_idle(dev_priv->dev)) {
+ if (i915_gem_gpu_idle(dev_priv->dev, true)) {
DRM_ERROR("Couldn't idle GPU\n");
/* Wait a bit, in hopes it avoids the hang */
udelay(10);
diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
index cdf17d4..8f27f2b 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -227,7 +227,7 @@ static int intel_overlay_do_wait_request(struct intel_overlay *overlay,
}
overlay->last_flip_req = request->seqno;
overlay->flip_tail = tail;
- ret = i915_wait_request(LP_RING(dev_priv), overlay->last_flip_req);
+ ret = i915_wait_request(LP_RING(dev_priv), overlay->last_flip_req, false);
if (ret)
return ret;
@@ -448,7 +448,7 @@ static int intel_overlay_recover_from_interrupt(struct intel_overlay *overlay)
if (overlay->last_flip_req == 0)
return 0;
- ret = i915_wait_request(LP_RING(dev_priv), overlay->last_flip_req);
+ ret = i915_wait_request(LP_RING(dev_priv), overlay->last_flip_req, false);
if (ret)
return ret;
--
1.7.7.1
^ permalink raw reply related
* Re: ping_pong test of ceph
From: mowang da @ 2011-10-31 1:21 UTC (permalink / raw)
To: ceph-devel
In-Reply-To: <CAF3hT9BEhwGVeiud0fDmBscB2KKc1uAJxvAEGQZ2KAW6pWOhTg@mail.gmail.com>
hi all,
this bug has been fixed yet? i can't find any information of it.
thanks for your help.
^ permalink raw reply
* Re: [PATCH 1/5] drm/i915: kicking rings stuck on semaphores considered harmful
From: Ben Widawsky @ 2011-10-31 1:25 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
In-Reply-To: <1320001932-1846-1-git-send-email-daniel.vetter@ffwll.ch>
On Sun, 30 Oct 2011 20:12:08 +0100
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> If our semaphore logic gets confused and we have a ring stuck waiting
> for one, there's a decent chance it'll just execute garbage when being
> kicked. Also, kicking the ring obscures the place where the error
> first occured, making error_state decoding much harder.
>
> So drop this an let gpu reset handle this mess in a clean fashion.
>
> In contrast, kicking rings stuck on MI_WAIT is rather harmless, at
> worst there'll be a bit of screen-flickering. There's also old
> broken userspace out there which needs this as a work-around.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reviewed-by: Chris Wilson <chris@hchris-wilson.co.uk>
> Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
> ---
> drivers/gpu/drm/i915/i915_irq.c | 7 -------
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b40004b..69d4044 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1649,13 +1649,6 @@ static bool kick_ring(struct intel_ring_buffer *ring)
> I915_WRITE_CTL(ring, tmp);
> return true;
> }
> - if (IS_GEN6(dev) &&
> - (tmp & RING_WAIT_SEMAPHORE)) {
> - DRM_ERROR("Kicking stuck semaphore on %s\n",
> - ring->name);
> - I915_WRITE_CTL(ring, tmp);
> - return true;
> - }
> return false;
> }
>
This also has the added benefit that it fixes a forcewake race on gen6+.
Ben
^ permalink raw reply
* Re: [PATCH 2/5] drm/i915: don't bail out of intel_wait_ring_buffer too early
From: Ben Widawsky @ 2011-10-31 1:29 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
In-Reply-To: <1320001932-1846-2-git-send-email-daniel.vetter@ffwll.ch>
On Sun, 30 Oct 2011 20:12:09 +0100
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> In the pre-gem days with non-existing hangcheck and gpu reset code,
> this timeout of 3 seconds was pretty important to avoid stuck
> processes.
>
> But now we have the hangcheck code in gem that goes to great length
> to ensure that the gpu is really dead before declaring it wedged.
>
> So there's no need for this timeout anymore. Actually it's even harmful
> because we can bail out too early (e.g. with xscreensaver slip)
> when running giant batchbuffers. And our code isn't robust enough
> to properly unroll any state-changes, we pretty much rely on the gpu
> reset code cleaning up the mess (like cache tracking, fencing state,
> active list/request tracking, ...).
>
> With this change intel_begin_ring can only fail when the gpu is
> wedged, and it will return -EAGAIN (like wait_request in case the
> gpu reset is still outstanding).
>
> v2: Chris Wilson noted that on resume timers aren't running and hence
> we won't ever get kicked out of this loop by the hangcheck code. Use
> an insanely large timeout instead for the HAS_GEM case to prevent
> resume bugs from totally hanging the machine.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index ca70e2f..6e28301 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1119,7 +1119,16 @@ int intel_wait_ring_buffer(struct intel_ring_buffer *ring, int n)
> }
>
> trace_i915_ring_wait_begin(ring);
> - end = jiffies + 3 * HZ;
> + if (drm_core_check_feature(dev, DRIVER_GEM))
> + /* With GEM the hangcheck timer should kick us out of the loop,
> + * leaving it early runs the risk of corrupting GEM state (due
> + * to running on almost untested codepaths). But on resume
> + * timers don't work yet, so prevent a complete hang in that
> + * case by choosing an insanely large timeout. */
> + end = jiffies + 60 * HZ;
> + else
> + end = jiffies + 3 * HZ;
> +
> do {
> ring->head = I915_READ_HEAD(ring);
> ring->space = ring_space(ring);
I didn't really check to see if there is actually an issue here, but
instead of 60, do you want to play nice with timeouts such as
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT (ie. the min of all the timeouts and
60)?
Acked-by: Ben Widawsky <ben@bwidawsk.net>
^ permalink raw reply
* Re: [PATCH 00/27 v7] m68k: Convert to genirq
From: Greg Ungerer @ 2011-10-31 1:29 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linux-kernel, Greg Ungerer
In-Reply-To: <1319978915-10933-1-git-send-email-geert@linux-m68k.org>
Hi Geert,
On 30/10/11 22:48, Geert Uytterhoeven wrote:
> This patch series converts the m68k/mmu (nommu was converted before)
> architecture to the generic hardirq framework.
>
> - [01/27] ide-{cd,floppy,tape}: Do not include<linux/irq.h>
> - [02/27] m68k/irq: Rename irq_controller to irq_chip
> - [03/27] m68k/irq: Kill irq_node_t typedef, always use struct irq_node
> - [04/27] m68k/irq: Rename irq_node to irq_data
> - [05/27] m68k/irq: Switch irq_chip methods to "struct irq_data *data"
> - [06/27] m68k/irq: Rename setup_irq() to m68k_setup_irq() and make it static
> - [07/27] m68k/irq: Extract irq_set_chip()
> - [08/27] m68k/irq: Add m68k_setup_irq_controller()
> - [09/27] m68k/irq: Rename {,__}m68k_handle_int()
> - [10/27] m68k/irq: Remove obsolete IRQ_FLG_* users
> - [11/27] m68k/irq: Add genirq support
> - [12/27] m68k/atari: Convert Atari to genirq
> - [13/27] m68k/atari: Remove code and comments about different irq types
> - [14/27] m68k/amiga: Refactor amiints.c
> - [15/27] m68k/amiga: Convert Amiga to genirq
> - [16/27] m68k/amiga: Optimize interrupts using chain handlers
> - [17/27] m68k/mac: Convert Mac to genirq
> - [18/27] m68k/mac: Optimize interrupts using chain handlers
> - [19/27] m68k/hp300: Convert HP9000/300 and HP9000/400 to genirq
> - [20/27] m68k/vme: Convert VME to genirq
> - [21/27] m68k/apollo: Convert Apollo to genirq
> - [22/27] m68k/sun3: Use the kstat_irqs_cpu() wrapper
> - [23/27] m68k/sun3: Convert Sun3/3x to genirq
> - [24/27] m68k/q40: Convert Q40/Q60 to genirq
> - [25/27] m68k/irq: Remove obsolete m68k irq framework
> - [26/27] m68k/irq: Remove obsolete support for user vector interrupt fixups
> - [27/27] m68k/mac: Remove mac_irq_{en,dis}able() wrappers
>
> Changes in v7:
> - Rebased after arch/m68k/Kconfig restructuring:
> - The temporary USE_GENERIC_HARDIRQS is now in arch/m68k/Kconfig,
> depending on MMU,
> - Rebased after arch/m68k/kernel/Makefile merge,
> - Split off IRQ_FLG_* removal in separate commits:
> - Postpone removals in drivers that should go through the respective
> driver trees (net/scsi/staging/serial),
> - Postpone final removal to v3.3,
> - Dropped (went in via another tree):
> - genirq: Add missing "else" in irq_shutdown(),
> - keyboard: Do not include<linux/irq.>,
> - Added Patch 27 ("m68k/mac: Remove mac_irq_{en,dis}able() wrappers")
>
> I added this to the m68k for-next and for-3.2 branches.
>
> I'll rebase it once more on top of v3.2-rc1 once that comes out (currently
> it's based on a random base point).
This all looks really good.
Acked-by: Greg Ungerer <gerg@uclinux.org>
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [PATCH 00/27 v7] m68k: Convert to genirq
From: Greg Ungerer @ 2011-10-31 1:29 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linux-kernel, Greg Ungerer
In-Reply-To: <1319978915-10933-1-git-send-email-geert@linux-m68k.org>
Hi Geert,
On 30/10/11 22:48, Geert Uytterhoeven wrote:
> This patch series converts the m68k/mmu (nommu was converted before)
> architecture to the generic hardirq framework.
>
> - [01/27] ide-{cd,floppy,tape}: Do not include<linux/irq.h>
> - [02/27] m68k/irq: Rename irq_controller to irq_chip
> - [03/27] m68k/irq: Kill irq_node_t typedef, always use struct irq_node
> - [04/27] m68k/irq: Rename irq_node to irq_data
> - [05/27] m68k/irq: Switch irq_chip methods to "struct irq_data *data"
> - [06/27] m68k/irq: Rename setup_irq() to m68k_setup_irq() and make it static
> - [07/27] m68k/irq: Extract irq_set_chip()
> - [08/27] m68k/irq: Add m68k_setup_irq_controller()
> - [09/27] m68k/irq: Rename {,__}m68k_handle_int()
> - [10/27] m68k/irq: Remove obsolete IRQ_FLG_* users
> - [11/27] m68k/irq: Add genirq support
> - [12/27] m68k/atari: Convert Atari to genirq
> - [13/27] m68k/atari: Remove code and comments about different irq types
> - [14/27] m68k/amiga: Refactor amiints.c
> - [15/27] m68k/amiga: Convert Amiga to genirq
> - [16/27] m68k/amiga: Optimize interrupts using chain handlers
> - [17/27] m68k/mac: Convert Mac to genirq
> - [18/27] m68k/mac: Optimize interrupts using chain handlers
> - [19/27] m68k/hp300: Convert HP9000/300 and HP9000/400 to genirq
> - [20/27] m68k/vme: Convert VME to genirq
> - [21/27] m68k/apollo: Convert Apollo to genirq
> - [22/27] m68k/sun3: Use the kstat_irqs_cpu() wrapper
> - [23/27] m68k/sun3: Convert Sun3/3x to genirq
> - [24/27] m68k/q40: Convert Q40/Q60 to genirq
> - [25/27] m68k/irq: Remove obsolete m68k irq framework
> - [26/27] m68k/irq: Remove obsolete support for user vector interrupt fixups
> - [27/27] m68k/mac: Remove mac_irq_{en,dis}able() wrappers
>
> Changes in v7:
> - Rebased after arch/m68k/Kconfig restructuring:
> - The temporary USE_GENERIC_HARDIRQS is now in arch/m68k/Kconfig,
> depending on MMU,
> - Rebased after arch/m68k/kernel/Makefile merge,
> - Split off IRQ_FLG_* removal in separate commits:
> - Postpone removals in drivers that should go through the respective
> driver trees (net/scsi/staging/serial),
> - Postpone final removal to v3.3,
> - Dropped (went in via another tree):
> - genirq: Add missing "else" in irq_shutdown(),
> - keyboard: Do not include<linux/irq.>,
> - Added Patch 27 ("m68k/mac: Remove mac_irq_{en,dis}able() wrappers")
>
> I added this to the m68k for-next and for-3.2 branches.
>
> I'll rebase it once more on top of v3.2-rc1 once that comes out (currently
> it's based on a random base point).
This all looks really good.
Acked-by: Greg Ungerer <gerg@uclinux.org>
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* [U-Boot] [PATCH V2] mvsata_ide: add delay after EDMA port reset -- PLEASE DISREGARD.
From: Albert ARIBAUD @ 2011-10-31 1:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320021522-20525-1-git-send-email-albert.u.boot@aribaud.net>
Le 31/10/2011 01:38, Albert ARIBAUD a ?crit :
> Although fast SoCs like kirkwood can cope without it,
> this delay is required by orion5x-based chips, either
> because they are slower, or because they run U-Boot
> from NOR, or both.
>
> Signed-off-by: Albert ARIBAUD<albert.u.boot@aribaud.net>
Please disregard my fit of 'post hoc ergo propter hoc' -- actually, IDE
works just fine on Orion without this "fix" of mine; the issues I have
with IDE sometimes not responding are due to some meddling from a CPLD
on the ED Mini V2, not to any timing associated with this patch.
I've marked V1 and V2 as Rejected in patchwork.
Amicalement,
--
Albert.
^ permalink raw reply
* Yocto weekly bug trend charts -- WW44
From: Xu, Jiajun @ 2011-10-31 1:34 UTC (permalink / raw)
To: yocto@yoctoproject.org
Hi all,
The overall open bug trend increased last week. Open bug and WDD number increased to 156 and 781. Bug status of WW44 could be found on https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend.
Best Regards,
Jiajun
^ permalink raw reply
* Re: [PATCH] parisc: futex: Use same lock set as lws calls
From: John David Anglin @ 2011-10-31 1:36 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: Rolf Eike Beer, linux-parisc
In-Reply-To: <CADZpyizsC-eSgCSyK52-Ns12z+mWUpFB8JH2dC2C7J_3EnGR5Q@mail.gmail.com>
On 30-Oct-11, at 8:21 PM, Carlos O'Donell wrote:
> On Sun, Oct 30, 2011 at 12:13 PM, John David Anglin
> <dave.anglin@bell.net> wrote:
>> On 30-Oct-11, at 11:31 AM, Rolf Eike Beer wrote:
>>
>>> John David Anglin wrote:
>>>
>>>> This problem is fixed in the GCC trunk and 4.4, 4.5 and 4.6
>>>> branches.
>>>> libmpfr4-3.1.0 now passes all tests.
>>>
>>> Can we get a link to a bug or a commit so we could easily put this
>>> into
>>> the
>>> gentoo patchset for local usage until a new version is released?
>>
>>
>> The trunk patch is on the gcc-patches list:
>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02758.html
>>
>> There are two variants of the patch:
>> http://gcc.gnu.org/viewcvs?view=revision&revision=180655
>> http://gcc.gnu.org/viewcvs?view=revision&revision=180662
>>
>> The first is for 4.7. The latter applies to 4.4, 4.5 and 4.6.
>
> Awesome! Great work Dave! :-)
Thanks, but this fix wasn't that hard... I had a little trouble with
the testing
due to other issues. Many GCC bugs are much harder. Things are easy
when the compilation bug is clear.
I integrated Guy's patch into debian 2.13-10 today and I was going to do
a build, but then I discovered it builds using 4.4. So, I patched 4.4
with the
above change, and will rebuild 2.13 when it's done. Hopefully, this
will
fix the udev bug which is blocking many python builds. I'm interested
to
see if the glibc testsuite results will be better.
It's a bit unclear how extensively TLS variables are used, but maybe
fixing
this will make it easier to resolve the remaining pthread bugs.
I've been wondering how much is left to install to glibc head?
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply
* Re: [PATCH v2] drm/i915: Fix recursive calls to unmap
From: Keith Packard @ 2011-10-31 1:36 UTC (permalink / raw)
To: intel-gfx; +Cc: Ben Widawsky
In-Reply-To: <1320024054-4732-1-git-send-email-ben@bwidawsk.net>
[-- Attachment #1.1: Type: text/plain, Size: 1541 bytes --]
On Sun, 30 Oct 2011 18:20:54 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
>
> The solution here is to add a new flag to the call chain which gives the
> routines the information they need to possibly defer actions which may
> cause us to recurse.
This looks a lot nicer; it's shorter than I feared too.
> @@ -2051,7 +2052,8 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj)
> * it.
> */
> if (obj->active) {
> - ret = i915_wait_request(obj->ring, obj->last_rendering_seqno);
> + ret = i915_wait_request(obj->ring, obj->last_rendering_seqno,
> + true);
> @@ -2400,7 +2402,8 @@ i915_gem_object_flush_fence(struct drm_i915_gem_object *obj,
> if (!ring_passed_seqno(obj->last_fenced_ring,
> obj->last_fenced_seqno)) {
> ret = i915_wait_request(obj->last_fenced_ring,
> - obj->last_fenced_seqno);
> + obj->last_fenced_seqno,
> + true);
> if (ret)
> return ret;
> }
> @@ -2541,7 +2544,8 @@ i915_gem_object_get_fence(struct drm_i915_gem_object *obj,
> if (!ring_passed_seqno(obj->last_fenced_ring,
> reg->setup_seqno)) {
> ret = i915_wait_request(obj->last_fenced_ring,
> - reg->setup_seqno);
> + reg->setup_seqno,
> + true);
> if (ret)
> return ret;
> }
Any reason you're changing behaviour outside of the area with the actual
problem? If so, you should stick those in a separate patch instead of
mixing them into this bug fix.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH] Final cosmetic/grammar/URL patches for QS Guide
From: Robert P. J. Day @ 2011-10-31 1:39 UTC (permalink / raw)
To: Yocto discussion list
One more set of patches for the QS Guide, covering the remainder of
the Guide from the kernel section to the end; mostly updating
filenames and URLs to reflect what actually exists these days.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
nothing earth-shaking here, just thought i'd finish off the QS guide
so i can move on to the next one. let me know if any of this is
incorrect.
diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
index 41da903..169b66a 100644
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -531,7 +531,7 @@
<para>
You can download the pre-built Linux kernel suitable for running in the QEMU emulator from
- <ulink url='http://yoctoproject.org/downloads/yocto-1.1/machines/qemu'></ulink>.
+ <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu'></ulink>.
Be sure to use the kernel that matches the architecture you want to simulate.
Download areas exist for the five supported machine architectures:
<filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
@@ -541,19 +541,15 @@
<para>
Most kernel files have one of the following forms:
<literallayout class='monospaced'>
- *zImage-<<emphasis>kernel-rev</emphasis>>-qemu<<emphasis>arch</emphasis>>-<<emphasis>release</emphasis>>*.bin
- vmlinux-<<emphasis>kernel-rev</emphasis>>-qemu<<emphasis>arch</emphasis>>-<<emphasis>release</emphasis>>*.bin
+ *zImage-qemu<<emphasis>arch</emphasis>>.bin
+ vmlinux-qemu<<emphasis>arch</emphasis>>.bin
Where:
- <<emphasis>kernel-rev</emphasis>> is the base Linux kernel revision
- (e.g. 2.6.37).
-
<<emphasis>arch</emphasis>> is a string representing the target architecture:
x86, x86-64, ppc, mips, or arm.
-
- <<emphasis>release</emphasis>> is the version of Yocto Project.
</literallayout>
</para>
+
<para>
You can learn more about downloading a Yocto Project kernel in the
@@ -568,7 +564,7 @@
<para>
You can also download the filesystem image suitable for your target architecture from
- <ulink url='http://yoctoproject.org/downloads/yocto-1.1/machines/qemu'></ulink>.
+ <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu'></ulink>.
Again, be sure to use the filesystem that matches the architecture you want
to simulate.
</para>
@@ -581,19 +577,17 @@
The <filename>tar</filename> form can be flattened out in your host development system
and used for Yocto Project build purposes.
<literallayout class='monospaced'>
- yocto-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>-<<emphasis>release</emphasis>>.rootfs.ext3.bz2
- yocto-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>-<<emphasis>release</emphasis>>.rootfs.tar.bz2
+ core-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>.ext3
+ core-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>.tar.bz2
Where:
<<emphasis>profile</emphasis>> is the filesystem image's profile:
- lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
+ lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
For information on these types of image profiles, see
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
<<emphasis>arch</emphasis>> is a string representing the target architecture:
x86, x86-64, ppc, mips, or arm.
-
- <<emphasis>release</emphasis>> is the version of Yocto Project.
</literallayout>
</para>
</section>
@@ -639,8 +633,8 @@
that the kernel and filesystem are for a 32-bit target architecture.
<literallayout class='monospaced'>
$ source /opt/poky/1.1/environment-setup-i686-poky-linux
- $ runqemu qemux86 bzImage-3.0-qemux86-1.1.bin \
- yocto-image-sato-qemux86-1.1.rootfs.ext3
+ $ runqemu qemux86 bzImage-qemux86.bin \
+ core-image-sato-qemux86.ext3
</literallayout>
</para>
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply related
* [U-Boot] [PATCH] nios2: Offer ft_board_setup() capability and call fdt_fixup_ethernet().
From: Thomas Chou @ 2011-10-31 1:43 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319631900-7758-1-git-send-email-joachim.foerster@missinglinkelectronics.com>
On 10/26/2011 08:25 PM, Joachim Foerster wrote:
> The main motivation is, to have the local-mac-address property of the
> ethernet peripherals fixed/synced with U-Boot's environment settings.
>
> Signed-off-by: Joachim Foerster<joachim.foerster@missinglinkelectronics.com>
> ---
> arch/nios2/cpu/Makefile | 1 +
> arch/nios2/cpu/fdt.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+), 0 deletions(-)
> create mode 100644 arch/nios2/cpu/fdt.c
Hi Joachim,
Applied. Thanks.
Best regards,
Thomas
^ permalink raw reply
* [U-Boot] [PATCH] sh: fix build error in cache.h
From: Yoshihiro Shimoda @ 2011-10-31 1:44 UTC (permalink / raw)
To: u-boot
In the latest U-Boot, the include/common.h includes the asm/cache.h.
So, the dcache_invalid_range() in the arch/sh/include/asm/cache.h is
multiple defination.
sh4-linux-gnu-ld -e 0x8FFC0000 --defsym reloc_dst=0x8FFC0000 -r -o libsh4.o cpu.o interrupts.o watchdog.o cache.o start.o
interrupts.o: In function `dcache_wback_range':
/home/u-boot/u-boot-sh/include/asm/cache.h:14: multiple definition of `dcache_wback_range'
cpu.o:/home/shimoda/development/u-boot/u-boot-sh/include/asm/cache.h:14: first defined here
interrupts.o: In function `dcache_invalid_range':
/home/u-boot/u-boot-sh/include/asm/cache.h:25: multiple definition of `dcache_invalid_range'
cpu.o:/home/shimoda/development/u-boot/u-boot-sh/include/asm/cache.h:25: first defined here
...
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
arch/sh/include/asm/cache.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sh/include/asm/cache.h b/arch/sh/include/asm/cache.h
index 6ffab4d..978cd8c 100644
--- a/arch/sh/include/asm/cache.h
+++ b/arch/sh/include/asm/cache.h
@@ -10,7 +10,7 @@ int cache_control(unsigned int cmd);
struct __large_struct { unsigned long buf[100]; };
#define __m(x) (*(struct __large_struct *)(x))
-void dcache_wback_range(u32 start, u32 end)
+static inline void dcache_wback_range(u32 start, u32 end)
{
u32 v;
@@ -21,7 +21,7 @@ void dcache_wback_range(u32 start, u32 end)
}
}
-void dcache_invalid_range(u32 start, u32 end)
+static inline void dcache_invalid_range(u32 start, u32 end)
{
u32 v;
--
1.7.1
^ permalink raw reply related
* [U-Boot] [PATCH] sh7763rdp: change config for new sh_eth driver
From: Yoshihiro Shimoda @ 2011-10-31 1:44 UTC (permalink / raw)
To: u-boot
The new sh_eth driver uses the phy driver. So, this patch enables it.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
include/configs/sh7763rdp.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/configs/sh7763rdp.h b/include/configs/sh7763rdp.h
index b8eb13d..59728f5 100644
--- a/include/configs/sh7763rdp.h
+++ b/include/configs/sh7763rdp.h
@@ -39,6 +39,7 @@
#define CONFIG_CMD_FLASH
#define CONFIG_CMD_MEMORY
#define CONFIG_CMD_NET
+#define CONFIG_CMD_MII
#define CONFIG_CMD_PING
#define CONFIG_CMD_SAVEENV
#define CONFIG_CMD_NFS
@@ -120,5 +121,8 @@
#define CONFIG_SH_ETHER 1
#define CONFIG_SH_ETHER_USE_PORT (1)
#define CONFIG_SH_ETHER_PHY_ADDR (0x01)
+#define CONFIG_PHYLIB
+#define CONFIG_BITBANGMII
+#define CONFIG_BITBANGMII_MULTI
#endif /* __SH7763RDP_H */
--
1.7.1
^ permalink raw reply related
* [U-Boot] [PATCH] sh: espt: change config for new sh_eth driver
From: Yoshihiro Shimoda @ 2011-10-31 1:44 UTC (permalink / raw)
To: u-boot
The new sh_eth driver uses the phy driver. So, this patch enables it.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
include/configs/espt.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/configs/espt.h b/include/configs/espt.h
index 38058c7..3df1fae 100644
--- a/include/configs/espt.h
+++ b/include/configs/espt.h
@@ -39,6 +39,7 @@
#define CONFIG_CMD_FLASH
#define CONFIG_CMD_MEMORY
#define CONFIG_CMD_NET
+#define CONFIG_CMD_MII
#define CONFIG_CMD_PING
#define CONFIG_CMD_ENV
#define CONFIG_CMD_NFS
@@ -120,5 +121,8 @@
#define CONFIG_SH_ETHER 1
#define CONFIG_SH_ETHER_USE_PORT (1)
#define CONFIG_SH_ETHER_PHY_ADDR (0x00)
+#define CONFIG_PHYLIB
+#define CONFIG_BITBANGMII
+#define CONFIG_BITBANGMII_MULTI
#endif /* __SH7763RDP_H */
--
1.7.1
^ permalink raw reply related
* Build Error Report
From: Masahiro Inoue @ 2011-10-31 1:35 UTC (permalink / raw)
To: linux-wireless
Hello,
The build error occurs by compat-wireless-2011-10-30.
My kernel is 2.6.27.
LD /home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros/atl1c/built-in.o
CC [M] /home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros/atl1c/atl1c_main.o
/home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros/atl1c/atl1c_main.c: In function 'atl1c_tx_map':
/home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros/atl1c/atl1c_main.c:2199: error: implicit declaration of function 'skb_frag_size'
/home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros/atl1c/atl1c_main.c: At top level:
/home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros/atl1c/atl1c_main.c:2926: warning: useless storage class specifier in empty declaration
/home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros/atl1c/atl1c_main.c:2926: warning: empty declaration
make[4]: *** [/home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros/atl1c/atl1c_main.o] Error 1
make[3]: *** [/home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros/atl1c] Error 2
make[2]: *** [/home/miyabi/test/compat-wireless/compat-wireless-2011-10-30/drivers/net/ethernet/atheros] Error 2
make[1]: *** [_module_/home/miyabi/test/compat-wireless/compat-wireless-2011-10-30] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.27-71vl5-x86_64'
make: *** [modules] Error 2
^ 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.