On Mon, Nov 12, 2018 at 03:43:37PM -0800, David Woodhouse wrote:
>
> That can't hurt. We should probably look at the time elapsed before you
> can *write* to it (when the background scan and crc checking is
> complete) rather than just reading.
>
Here are more data points. This is again with 10
On Mon, Nov 12, 2018 at 03:43:37PM -0800, David Woodhouse wrote:
>
> That can't hurt. We should probably look at the time elapsed before you
> can *write* to it (when the background scan and crc checking is
> complete) rather than just reading.
>
I'm not sure how to test that, but I tried this,
On Mon, 2018-11-12 at 15:40 -0800, Daniel Walker wrote:
> On Mon, Nov 12, 2018 at 03:11:32PM -0800, David Woodhouse wrote:
> > On Mon, 2018-11-12 at 14:50 -0800, Daniel Walker wrote:
> > > Performance counter stats for 'mount -t jffs2 /dev/mtdblock7 /mnt':
> >
> > Hm, how many decades will it tak
On Mon, Nov 12, 2018 at 03:11:32PM -0800, David Woodhouse wrote:
> On Mon, 2018-11-12 at 14:50 -0800, Daniel Walker wrote:
> > Performance counter stats for 'mount -t jffs2 /dev/mtdblock7 /mnt':
>
> Hm, how many decades will it take for the 'mtdblock' thing to die?
> JFFS2 doesn't use block devic
On Mon, 2018-11-12 at 14:50 -0800, Daniel Walker wrote:
> Performance counter stats for 'mount -t jffs2 /dev/mtdblock7 /mnt':
Hm, how many decades will it take for the 'mtdblock' thing to die?
JFFS2 doesn't use block devices :)
> It looks like the took slightly more than twice as long to mount.
On Mon, Nov 12, 2018 at 01:43:33PM -0800, Daniel Walker wrote:
> On Thu, Nov 08, 2018 at 07:47:08PM +, David Woodhouse wrote:
> > On Thu, 2018-11-08 at 18:01 +, Nikunj Kela (nkela) wrote:
> > > But we can hypothesise and handwave about it until the cows come home;
> > > I'd like to
On Thu, Nov 08, 2018 at 07:47:08PM +, David Woodhouse wrote:
> On Thu, 2018-11-08 at 18:01 +, Nikunj Kela (nkela) wrote:
> > But we can hypothesise and handwave about it until the cows come home;
> > I'd like to see a real test of whether it actually makes a difference
> > that
On Thu, 2018-11-08 at 18:01 +, Nikunj Kela (nkela) wrote:
> But we can hypothesise and handwave about it until the cows come home;
> I'd like to see a real test of whether it actually makes a difference
> that we care about.
>
> If it does, one option might be to just build
On Thu, 2018-11-08 at 18:01 +, Nikunj Kela (nkela) wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On 11/8/18, 12:12 AM, "David Woodhouse" wrote:
>
>
On 11/8/18, 12:12 AM, "David Woodhouse" wrote:
On Wed, 2018-11-07 at 19:14 +0100, Richard Weinberger wrote:
> On Wed, Nov 7, 2018 at 7:05 PM Nikunj Kela (nkela)
wrote:
> > I had tried to use configs to start with via the following patch
however I was advised to have a mount option
On Wed, Nov 07, 2018 at 06:41:47PM +, Joakim Tjernlund wrote:
> > Certainly not. I'm not sure which architectures do have Spectre V2
> > mitigations which make indirect branches expensive now... perhaps there is
> > no intersection with the cases where we really care about JFFS2 being
> > CPU-b
On Wed, 2018-11-07 at 19:14 +0100, Richard Weinberger wrote:
> On Wed, Nov 7, 2018 at 7:05 PM Nikunj Kela (nkela) wrote:
> > I had tried to use configs to start with via the following patch however I
> > was advised to have a mount option:
> > http://lists.infradead.org/pipermail/linux-mtd/2018-N
On Wed, Nov 07, 2018 at 05:58:53PM -, David Woodhouse wrote:
>
> > On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse wrote:
> >>
> >> > Yes, this may slow things down. I am not sure I agree with the impl.
> >> > either.
> >> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr wh
On Wed, 2018-11-07 at 17:58 +, David Woodhouse wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> > On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse
On Wed, Nov 7, 2018 at 7:05 PM Nikunj Kela (nkela) wrote:
> I had tried to use configs to start with via the following patch however I
> was advised to have a mount option:
> http://lists.infradead.org/pipermail/linux-mtd/2018-November/085126.html
Just show performance numbers on how your implem
On 11/7/18, 1:05 AM, "David Woodhouse" wrote:
On Tue, 2018-11-06 at 13:49 -0800, Nikunj Kela wrote:
>> This patch allows the endianness of the JFSS2 filesystem to be
>> specified by mount option 'force_endian=big|little|native'. If
>> endianness is not specified, it defaults to 'na
> On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse wrote:
>>
>> > Yes, this may slow things down. I am not sure I agree with the impl.
>> > either.
>> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set
>> to
>> > a func. with the correct endian?
>>
>> On x86 retpolin
On Wed, Nov 07, 2018 at 04:12:14PM -, David Woodhouse wrote:
>
> > Yes, this may slow things down. I am not sure I agree with the impl.
> > either.
> > Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set to
> > a func. with the correct endian?
>
> On x86 retpoline would make
> Yes, this may slow things down. I am not sure I agree with the impl.
> either.
> Could one not make cpu_to_je_X/jeX_to_cpu a function ptr which is set to
> a func. with the correct endian?
On x86 retpoline would make that quite slow.
--
dwmw2
On Wed, 2018-11-07 at 10:05 +0100, David Woodhouse wrote:
>
> On Tue, 2018-11-06 at 13:49 -0800, Nikunj Kela wrote:
> > This patch allows the endianness of the JFSS2 filesystem to be
> > specified by mount option 'force_endian=big|little|native'. If
> > endianness is not specified, it defaults to
On Tue, 2018-11-06 at 13:49 -0800, Nikunj Kela wrote:
> This patch allows the endianness of the JFSS2 filesystem to be
> specified by mount option 'force_endian=big|little|native'. If
> endianness is not specified, it defaults to 'native' endianness
> thus retaining the existing behavior.
>
> Some
This patch allows the endianness of the JFSS2 filesystem to be
specified by mount option 'force_endian=big|little|native'. If
endianness is not specified, it defaults to 'native' endianness
thus retaining the existing behavior.
Some architectures benefit from having a single known endianness
of JF
22 matches
Mail list logo
