date:20140311

Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

2014-03-11 Thread Kevin Hao

On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
> > +   FSL_DIS_ALL_IRQ
> > +
> > +   /*
> > +* Place DDR controller in self refresh mode.
> > +* From here on, DDR can't be access any more.
> > +*/
> > +   lwz r10, 0(r13)
> > +   orisr10, r10, CCSR_DDR_SDRAM_CFG_2_FRC_SR@h
> > +   stw r10, 0(r13)
> > +
> > +   /* can't call udelay() here, so use a macro to delay */
> > +   FSLDELAY(50)
> 
> A timebase loop doesn't require accessing DDR.
> 
> You also probably want to do a "sync, readback, data dependency, isync"
> sequence to make sure that the store has hit CCSR before you begin your
> delay (or is a delay required at all if you do that?).

Shouldn't we use "readback, sync" here? The following is quoted form t4240RM:
  To guarantee that the results of any sequence of writes to configuration
  registers are in effect, the final configuration register write should be
  immediately followed by a read of the same register, and that should be
  followed by a SYNC instruction. Then accesses can safely be made to memory
  regions affected by the configuration register write.

> > +
> > +   /* Enable SCU15 to trigger on RCPM Concentrator 0 */
> > +   lwz r10, 0(r15)
> > +   orisr10, r10, DCSR_EPU_EPECR15_IC0@h
> > +   stw r10, 0(r15)
> > +
> > +   /* put Core0 in PH15 mode, trigger EPU FSM */
> > +   lwz r10, 0(r12)
> > +   ori r10, r10, CCSR_RCPM_PCPH15SETR_CORE0
> > +   stw r10, 0(r12)
> 
> Shouldn't there be a sync to ensure that the previous I/O happens before
> the final store to enter PH15?

Do we really need a sync here? According to the PowerISA, the above stores
should be performed in program order.
  If two Store instructions or two Load instructions
  specify storage locations that are both Caching
  Inhibited and Guarded, the corresponding storage
  accesses are performed in program order with
  respect to any processor or mechanism.

Thanks,
Kevin

pgp3W0oJZFfr6.pgp
Description: PGP signature

RE: Subject: [PATCH] mm: use vm_map_ram for only temporal object

2014-03-11 Thread Gioh Kim

Hello,

I got a mail from Andrew Morton that
he fixed my typo and poor English 
like this: 
http://ozlabs.org/~akpm/mmots/broken-out/mm-vmallocc-enhance-vm_map_ram-comment-fix.patch

Thank you for your attention.



> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of SeongJae Park
> Sent: Tuesday, March 11, 2014 8:51 PM
> To: Gioh Kim
> Cc: Zhang Yanfei; Minchan Kim; Andrew Morton; Joonsoo Kim; linux-
> m...@kvack.org; linux-kernel@vger.kernel.org; 이건호; chanho@lge.com;
> Johannes Weiner
> Subject: Re: Subject: [PATCH] mm: use vm_map_ram for only temporal object
> 
> Hello Gioh,
> 
> On Mon, Mar 10, 2014 at 7:16 PM, Gioh Kim  wrote:
> >
> > The vm_map_ram has fragment problem because it couldn't purge a
> > chunk(ie, 4M address space) if there is a pinning object in that
> > addresss space. So it could consume all VMALLOC address space easily.
> > We can fix the fragmentation problem with using vmap instead of
> > vm_map_ram but vmap is known to slow operation compared to vm_map_ram.
> > Minchan said vm_map_ram is 5 times faster than vmap in his experiment.
> > So I thought we should fix fragment problem of vm_map_ram because our
> > proprietary GPU driver has used it heavily.
> >
> > On second thought, it's not an easy because we should reuse freed
> > space for solving the problem and it could make more IPI and bitmap
> > operation for searching hole. It could mitigate API's goal which is very
> fast mapping.
> > And even fragmentation problem wouldn't show in 64 bit machine.
> >
> > Another option is that the user should separate long-life and
> > short-life object and use vmap for long-life but vm_map_ram for short-
> life.
> > If we inform the user about the characteristic of vm_map_ram the user
> > can choose one according to the page lifetime.
> >
> > Let's add some notice messages to user.
> >
> > Signed-off-by: Gioh Kim 
> > Reviewed-by: Zhang Yanfei 
> > ---
> >  mm/vmalloc.c |6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 0fdf968..85b6687 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -1083,6 +1083,12 @@ EXPORT_SYMBOL(vm_unmap_ram);
> >   * @node: prefer to allocate data structures on this node
> >   * @prot: memory protection to use. PAGE_KERNEL for regular RAM
> >   *
> > + * If you use this function for below VMAP_MAX_ALLOC pages, it could
> > + be faster
> > + * than vmap so it's good. But if you mix long-life and short-life
> > + object
> > + * with vm_map_ram, it could consume lots of address space by
> > + fragmentation
> > + * (expecially, 32bit machine). You could see failure in the end.
> 
> looks like trivial typo. Shouldn't s/expecially/especially/ ?
> 
> Thanks.
> 
> > + * Please use this function for short-life object.
> > + *
> >   * Returns: a pointer to the address that has been mapped, or %NULL on
> failure
> >   */
> >  void *vm_map_ram(struct page **pages, unsigned int count, int node,
> > pgprot_t prot)
> > --
> > 1.7.9.5
> >
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in the body
> > to majord...@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [RESEND v2 PATCH 1/2] aio, memory-hotplug: Fix confliction when migrating and accessing ring pages.

2014-03-11 Thread Tang Chen

Hi Ben,

Sorry for the delay.

On 03/12/2014 02:46 AM, Benjamin LaHaise wrote:

On Mon, Mar 10, 2014 at 04:15:33PM +0800, Tang Chen wrote:

IO ring page migration has been implemented by the following patch:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/aio.c?id=36bc08cc01709b4a9bb563b35aa530241ddc63e3

In this patch, ctx->completion_lock is used to prevent other processes
from accessing the ring page being migrated.

But in aio_setup_ring(), ioctx_add_table() and aio_read_events_ring(),
when writing to the ring page, they didn't take ctx->completion_lock.

As a result, for example, we have the following problem:

...

As above, the new ring page will not be updated.

The solution is taking ctx->completion_lock in thread 2, which means,
in aio_setup_ring(), ioctx_add_table() and aio_read_events_ring() when
writing to ring pages.

Upon review, there are still two accesses of ->ring_pages that are not
protected by any spinlocks which could potentially race with migration. One
is in aio_setup_ring(), which can be easily resolved by moving the assignment
of ->ring_pages above the unlock_page().

Yes， you are right. Followed, thanks.

Another spot is in
aio_read_events_ring() where head and tail are fetched from the ring without
any locking. I also fear we'll be introducing new performance issues with
all the additonal spinlock bouncing, despite the fact that is only ever
needed for migration. I'm going to continue looking into this today and
will try to send out a followup to this email later.

In the beginning of aio_read_events_ring(), it reads head and tail, not
write.
So even if ring pages are migrated, the contents of the pages will not
be changed.

So reading it is OK, from old page or from the new page, I think.

-ben

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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1640 matches

Mail list logo