Hi,
Data transformation (EC, encryption, etc) is commonly done by storage systems
today. But let's think about other less common existing and PM specific
upcoming features like data sharing between multiple consumers (computers for
example), support for atomicity (to avoid journaling in PM spa
I am trying to refocus this thread from a particular issue to more generic
needs...
Regards, Boris
> -Original Message-
> From: Matthew Wilcox [mailto:wi...@linux.intel.com]
> Sent: Tuesday, September 30, 2014 3:24 PM
> To: Zuckerman, Boris
> Cc: Matthew Wilcox; valdis.k
>
> The more I think about this, the more I think this is a bad idea.
> When you have a file open with O_DIRECT, your I/O has to be done in 512-byte
> multiples, and it has to be aligned to 512-byte boundaries in memory. If an
> unsuspecting application has O_DIRECT forced on it, it isn't going t
2 years ago I had that type of functionality implemented for Ibrix. It included
readdir-ahead and lookup-ahead. We did not assume any new syscalls, simply
detected readdir+ like interest on VFS level and pushed a wave of populating
directory caches and plugging in dentry cache entries. It improv
Matthew,
First of all, thank you for doing this job!
Supporting persistent memory for any OS is bit more than adding "just another
device".
There are some thoughts and questions below. Perhaps, you discussed those
already. If so, please point me to that discussion!
> > Few questions:
> > - wh
Hi,
You probably already considered that - sorry, if so…
Instead of the mutex Windows use ExecutiveResource with shared and exclusive
semantics. Readers serialize by taking the resource shared and writers take it
exclusive. I have that implemented for Linux. Please, let me know if there is
any
drivers to do their, right?
boris
> -Original Message-
> From: Matthew Wilcox [mailto:wi...@linux.intel.com]
> Sent: Thursday, September 26, 2013 1:56 PM
> To: Zuckerman, Boris
> Cc: Vladislav Bolkhovitin; rob.gitt...@linux.intel.com;
> linux-p...@lists.infradead.org;
> li
In support to what was said by Vlad:
To work with persistent memory as efficiently as we can work with RAM we need a
bit more than "commit". It's reasonable to expect that we get some additional
support from CPUs that goes beyond mfence and mflush. That may include
discovery, transactional supp
> Sent: Thursday, September 05, 2013 4:44 PM
> To: Zuckerman, Boris; Jeff Moyer; Matthew Wilcox
> Cc: linux-p...@lists.infradead.org; rob.gitt...@linux.intel.com; linux-
> ker...@vger.kernel.org
> Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs
>
>
> Hi Boris,
>
Hi,
It's a great topic! I am glad to see this conversation happening...
Let me try to open another can of worms...
Persistent memory updates are more like DB transactions and less like flushing
IO ranges.
If someone offers commitpmem() functionality, someone has to assure that all
updates bef
10 matches
Mail list logo
