similar to: [LLVMdev] Using address space attribute in LLVM

On Oct 19, 2009, at 8:40 AM, Juan Carlos Martinez Santos wrote: > Hello, > > What is the correct way to use address_space attribute? For CLANG, I > used the below code, but when I tried the same with LLVM, I got a > warning. llvm-gcc doesn't support address spaces. This is a clang-only feature. -Chris > > Thanks in advance, > > Juan Carlos > >

On Fri, Jan 21, 2011 at 4:32 PM, Aaron Myles Landwehr <snaphat at gmail.com> wrote: > Hypothetically, suppose I have a generic system with multiple address spaces > such that each address space is accessed using different instructions. > Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of > c variables and function return types such that

Hi all, Hypothetically, suppose I have a generic system with multiple address spaces such that each address space is accessed using different instructions. Now suppose, I wanted to add a new keywords 'foo' and 'bar' to the front of c variables and function return types such that the following would be valid: foo void* a; foo void* somefunc(){...} bar int b; int somefunc2(bar

I sent a patch about page allocation for less fragmentation. http://permalink.gmane.org/gmane.linux.kernel.mm/130599 It proposes a page allocator allocates pages in the same pageblock for the drivers to move their unmovable pages. Some drivers which comsumes many pages and increases system fragmentation use the allocator to move their pages to decrease fragmentation. I think I can try another

I sent a patch about page allocation for less fragmentation. http://permalink.gmane.org/gmane.linux.kernel.mm/130599 It proposes a page allocator allocates pages in the same pageblock for the drivers to move their unmovable pages. Some drivers which comsumes many pages and increases system fragmentation use the allocator to move their pages to decrease fragmentation. I think I can try another

Hello, We would like to propose a way for improving the diagnostics for address_space by being able to pass strings as an argument to it instead of just an integer. This was initially proposed before (http://lists.llvm.org/pipermail/cfe-dev/2018-August/058702.html) but did not focus on it at the time. Reasoning: Clang's __attribute__((address_space(...))) feature uses an arbitrary integer as

+cfe-dev at lists.llvm.org On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > Stash a lookup table from integers to strings in Context and dynamically allocate integers for new strings. You can then keep integers in most of the code, writing/displaying strings for the integers with an entry in the table when writing to files or displaying. > >

Per Vlastimil's review comment, Vlastimil, I updated based on your comment. Please review this. If everything is done, I will send v7 rebased on recent mmotm. Thanks for the review! >From ad4157e98651a2d18fd0a4ae90d1d9f609aab314 Mon Sep 17 00:00:00 2001 From: Minchan Kim <minchan at kernel.org> Date: Fri, 8 Apr 2016 10:34:49 +0900 Subject: [PATCH v6r2] mm: migrate: support non-lru

Per Vlastimil's review comment, Vlastimil, I updated based on your comment. Please review this. If everything is done, I will send v7 rebased on recent mmotm. Thanks for the review! >From ad4157e98651a2d18fd0a4ae90d1d9f609aab314 Mon Sep 17 00:00:00 2001 From: Minchan Kim <minchan at kernel.org> Date: Fri, 8 Apr 2016 10:34:49 +0900 Subject: [PATCH v6r2] mm: migrate: support non-lru

On Tue, Jun 2, 2015 at 10:27 AM, Gioh Kim <gioh.kim at lge.com> wrote: > Apply driver page migration into balloon driver. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 2 ++ > fs/proc/page.c | 4 +-- > include/linux/balloon_compaction.h | 42 ++++++++++++++++------- >

On Tue, Jun 2, 2015 at 10:27 AM, Gioh Kim <gioh.kim at lge.com> wrote: > Apply driver page migration into balloon driver. > > Signed-off-by: Gioh Kim <gioh.kim at lge.com> > --- > drivers/virtio/virtio_balloon.c | 2 ++ > fs/proc/page.c | 4 +-- > include/linux/balloon_compaction.h | 42 ++++++++++++++++------- >

On Mon, May 30, 2016 at 11:36:07AM +0200, Vlastimil Babka wrote: > On 05/30/2016 03:39 AM, Minchan Kim wrote: > >After isolation, VM calls migratepage of driver with isolated page. > >The function of migratepage is to move content of the old page to new page > >and set up fields of struct page newpage. Keep in mind that you should > >clear PG_movable of oldpage via

On Mon, May 30, 2016 at 11:36:07AM +0200, Vlastimil Babka wrote: > On 05/30/2016 03:39 AM, Minchan Kim wrote: > >After isolation, VM calls migratepage of driver with isolated page. > >The function of migratepage is to move content of the old page to new page > >and set up fields of struct page newpage. Keep in mind that you should > >clear PG_movable of oldpage via

Thanks again for your help! > >> > >> Probably fairly minimal in most cases (on x86). On ARM there is > >> definitely a cost. > >> > > hm... why? You cannot have indexed addressing? > What I need is a way to force > The code that needs to be emitted is roughly: > [..."segment"-offset into x1...] > mrs x0, tpidr_el0 >

Thank you for the prompt response, Matt. On Jan 20, 2014, at 3:03 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > Since 3.4 you need to use the addrspacecast instruction to cast between address spaces. It's possible there are still some places left that haven't been fixed yet to use it instead of creating bit casts. Are you saying you think this is a bug and it should

Mark the function virtballoon_migratepage() as static in virtio_balloon.c because it is not used outside this file. This eliminates the following warning in virtio_balloon.c: drivers/virtio/virtio_balloon.c:372:5: warning: no previous prototype for ?virtballoon_migratepage? [-Wmissing-prototypes] Signed-off-by: Rashika Kheria <rashika.kheria at gmail.com> ---

Mark the function virtballoon_migratepage() as static in virtio_balloon.c because it is not used outside this file. This eliminates the following warning in virtio_balloon.c: drivers/virtio/virtio_balloon.c:372:5: warning: no previous prototype for ?virtballoon_migratepage? [-Wmissing-prototypes] Signed-off-by: Rashika Kheria <rashika.kheria at gmail.com> ---

On (05/09/16 11:20), Minchan Kim wrote: [..] > +++ b/include/linux/migrate.h > @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES]; > > #ifdef CONFIG_MIGRATION > > +extern int PageMovable(struct page *page); > +extern void __SetPageMovable(struct page *page, struct address_space *mapping); > +extern void __ClearPageMovable(struct page *page); > extern

On (05/09/16 11:20), Minchan Kim wrote: [..] > +++ b/include/linux/migrate.h > @@ -32,11 +32,16 @@ extern char *migrate_reason_names[MR_TYPES]; > > #ifdef CONFIG_MIGRATION > > +extern int PageMovable(struct page *page); > +extern void __SetPageMovable(struct page *page, struct address_space *mapping); > +extern void __ClearPageMovable(struct page *page); > extern

On Tue, Mar 22, 2016 at 11:55:45PM +0900, Minchan Kim wrote: > On Tue, Mar 22, 2016 at 02:50:37PM +0900, Joonsoo Kim wrote: > > On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote: > > > We have allowed migration for only LRU pages until now and it was > > > enough to make high-order pages. But recently, embedded system(e.g., > > > webOS, android) uses